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Oedicatad to Sstiierv who knoss more about 
ACP's than any other 370 programaer in the 
world. 



This docuraent is written by an RSX-llM user for RSX-llM 
users. The Initial seed for this docunent was planted when I 
researched a project to implement DECMET DAP protocol at the FCS 
level and disc over ed^ contrary to popular belief^ there is 
nothing to prevent an user from writing an ACP. Quite the 
contrary^ I can now impiament ACP's as easily as device drivers. 

The one thing lacking is documentation- This is my attempt 
to fill the gap and save others the long nights spent poring 
over listings and manuals- This is not to say ACP's are 
trivial. It is important to remember that while the concept of 
an ACP is simple^ the implementation will be as difficult as the 
problem you are attempting to soive- 

The manual is directed towards three types of readers. 
First is the developer faced with the task of writing an ACP. 
The entire manual applies to such a reader- Before refering to 
this material^ the RSX— IIM Guide to Mrlting an I/O Driver and 
the chapters in the RSX-llM System Logic Manual on the I/O 
mechanisa and data structures should be covered- 

Mext/ the manual can be used by someone who merely wants a 
batter understanding of the ACP mechanism- The first three 
chapters should be sufficient for an introduction- Finally, the 
manual can be used for reference- In particular, the appendices 
contains useful reference material. 

A sample ACP and supporting enabling and disabling ta^s 
have been developed to be used with the manual. The source code 
should also be studied, especially when reading chapter 3- The 
sample code can also be used as a basis for a user-written ACP. 

This document reflects ACP's as of version RSX-llM ¥3.2. 
It does not apply to IAS or 7AX/VMS- The thrust of the document 
is how to fit an ACP into RSX-llM^ not how to write any specific 
ACP. 

Raturally, neither the author, Monsanto, nor DSCDS claim 
any responsibility of the accuracy for the material in this 
document. Ii mistakes are found or misinterpretations occur, 
please notify the author so that the material can be corrected. 
ACP '3 are moving targets and, at best, this document can only 
move slightly behind them. 




The reader snouid be aware that some material has only 
recently been added and ihas not been oroofreaci by anyone but the 
author. This includes all of chapters 4/ 5^ and 6. the manual 
snouid be considaced with a yrain of salt^ especially/ the new 
Chapters. 

The manual would have bean lapossible without the aid of 
many people. The aanagefflent of the Monsanto Agricultural 
Research depaxtinent, especially John Schaefer and Larry Jasper# 
must he thanked for providing an environment that allows 
programmers to be iiaaginative. From the R3X SIG# Rick Aurbach# 
Fred Veck, John Mood# and Jia McGllnchey have all contributed 
ideas and time. Jim and Rick has been especially valuable in 
edltting the material and providing insight into how the 
material should be presented- Finally# the manual would never 
have been completed without the constant aid of by wife# Esther. 



Ralph Stamerjohn 
Monsanto# Zone TIA 
800 M- Lindbergh 
St- Louis# MQ, 63166 
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CHAPTER 1 



ACP PHILOSOPHY 



AncHlary Control Processors (ACP's) are an integral 
component of the RSX-llM operating system. Yet they remain one 
of the least understood portions of the system. This chapter 
will develop a definition for **ACP" and explore the 
functionality ACP's provide in an RSX-llM system. 



1.1 DEFINITIOxY OF **ACP»» 



Ancillary control processors are a part of the RSX-llM I/O 
mechanism. They implement device protocols for a variety of I/O 
devices. Because the operation of ACP's is hidden from the 
programmer, they have been considered untouchable in the past. 
Conceptually, however, an ACP is nothing more than a task which 
is tied to a device driver via the I/O mechanism. As this 
manual will show, the interface between an ACP and a driver is 
very simple and allows ACP's to be a powerful tool for system 
developers. 

Every operating system's I/O mechanism can be broken into 
various functional components. At the lowest level are the 
device service routines. These routines perform the actual 
device I/O. The next level are the device protocol routines. 
The protocols allow various devices to be classed together as a 
single logical type and extend the device functionality beyond 
the actual device capabilities. File systems and communications 
protocols fall into this class- At the next level is the 
mechanism for program I/O requests. The same mechanism can be 
used for each device or different devices may use different 
methods. The final level of functionality are the logical I/O 
services. Record I/O falls into this category. Logical I/Q 
services allow data to be represented in logical, rather than 
the actual machine format. In many systems, this level is also 
used to implement device indepandence- 

Mhiie different operating systems use different 
implementations for their I/O mechanism, similarities do exist. 
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Davica service routines are usually included in the monitor 
bacaush of their requireraants for responsiveness and close 
coupling aith the hardware devices. On the other hand/ while a 
property of the operating system#, davica protocol code is 
usually excluded from the kernel monitor because of its 
complexity and size. Some mechanism is used to allow the device 
protocol code to communicate with the device service routine. 

RSX-llM uses ACP's to implement device protocols. The 
concept of an ACP was first used for R3X-11D. Each device was 
serviced by a task which also contained the interrupt service 
code. These tasks wars called device handlers and allowed the 
programmer to use the power of both task and executive state- 
For very complicated protocols such as the file system/ other 
tasks were used to perform the various file I/O functlons- 

This approach suffered from several flaws. For simple 
devices such as line printers/ using a task for device service 
was overkill. For complex devices/ the structural llaitations 
complicated the implementation. Mhen RSX-llM was introduced/ 
device service and device protocol were separated into distinct 
components- Simple device drivers were included in the kernel 
executive. Special tasks (ACP's) were coupled to the executive 
to perform the device protocols. The coupling mechanism has 



changed with various releases/ but 
components has remained. 


the 


separation 


of 


the 


two 


In 


summary/ an ACP is a task 


which 


is tied 


to 


the 


I/Q 



mechanism and is used to provide a protocol for a class of 
devices. ACP's enjoy both the features of a task and the power 
of the executive. As will be shown later/ the coupling of ACP's 
to the executive and device drivers is very simple/ making 
user-written ACP's a workable solution to a wide variety of 
application problems - 



1.2 AC? CHARACTERISTICS 



Several ACP 's have been written by Digital. The common 
Digital ACP's are the the disk file system (FllACP)/ AMSl 
magtapes (MTAACP)/ and the MSP portion of DECMET (MET ACP). 
These AC? '3 have the following attributes and characteristics. 

1. Each ACP is a privileged task and has ail the 
attributes of a task (stack/ priority/ task name/ 
chackpointiag/ ate.). 

2- Each ACP can be considered a portion the executlve- 
ACP's are mapped into the executive and run in kernel 
state whenever necessary. 
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3» Each AC? iaplaiaents a protocol for a class of devicesi 

1. FllAC? iiaplsfflents the Files-il protocol for all 
disks (RS05^ RP06, etc. } and 0£Ctapes« ' 

2. MTAIC? iapleaents the AMSl aagtape protocol for ail 
supported tape drives (TUIO#^ TE16, etc.). 

3. MET ACP laplements the MSP portion of the DECNET 
protocol for a uide variety of coamunlcation 
interfaces (DLll, OMCll, etc.). 



4. The protocols extend the f imctionality of the devices 

in several Mays: 

1- The burden of direct device manipulation is removed 
from the programBer and is bandied by the ACP in 
conjunction with the device drivers. 

2- The burden of protocol level data manipulation is 
handled by the ACP's. The ACP's strip any data 
related to protocol and return only the Information 
related to the application. 

3. The ACP's allOM the devices to function as logical^ 
rather than physical, entitles. In the case of 
Files-11, a program deals Mith files instead of 
physical disk blocks. FllACP handles all block 
mapping and allocation. Programs view files as a 
set of contiguous blocks, regardless of the actual 
allocation. 

4. The ACP's allow different devices to be treated the 
same from the program's vieMpoint- DECNET's 
support of logical links over asynchronous, 
synchronous, and parallel interfaces is the most 
vivid example of this. 

5. The devices can be shared for simultaneous access. 
Each accessing process is protected from others by 
the ACP's. The ACP's also synchronize access to 
the physical devices when necessary. 

6. The devices are protected against unauthorized and 
destructive access. Mhen an ACP is used with a 
device, the AC? '*OMns'* the device. 



5* Each ACP can be aounted/dismounted for a given device - 
Mhan mounted, the device is available only for use In 
the context of the device protocol provided by the ACP. 
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One lack of sicailarity iaust also be aentioned- The 
intarnai Impiementation of the Digital ACF's hatre nothing in 
coffifflon. The only siajilarities are in the interface to the 
operating systaa. How an AC? accoBspiishas its purpose is left 
to tne indi'/iduai ACP. 



1.3 I/O BIESARCHY 



As was stated before^ all I/O mechanisias can be broken into 
four functional components: logical I/O services, program I/O 
requests, device handling, and device protocol services. Ihis 
section will discuss how each of these functional components ace 
impleniented by R3X-11M. In particular, the relationship of each 
component to an ACP will be discussed. 



The 1/0 mechanism for RSX-llM can be mapped directly into 
the four areas. The FCS/RMS libraries provide the logical I/O 
services. The QIO directive and the associated executive 
processing form the I/O request mechanism- Device drivers are 
used for device service. And finally, ACP's are used to 
iaplement device protocols. 



1.3.1 fCS/RMS 



Logical I/O services for RSX-llM are provided by the 
file/record service libraries: Record Management Services (RMS) 
and File Control Services (FCS). The two most important 
services provided by these packages are device independence and 
logical records- The packages also provide a convenient 
programming interface for issuing I/O raquests- 

Both FCS and RMS are implemented as macro and subroutine 
libraries- RMS is the newer package- It extends the concept of 
logical records, particularly in the area of record organization 
(relative and keyed). FCS is the traditional package and is 
more widely used in RSX-llM systems- However, the libraries ace 
equivalent in their relationship to the other components of the 
I/O mechanism. 



Whan called, FCS/RMS translate the iogicai I/O requests 
into device specific I/O requests. This is dona by examining 
the characteristics of the assigned device and issuing the 
appropriate QIO dir actives. The packages are also aware of the 
existence of the Fiias-11 and magtape ACP's and issue I/O 
requests specific to tahese ACP's. It is important to remember 
that FCS/RMS do not implament the file system, they are only 
aware of how to interface to it to accomplish the services 
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requested by the programmer. A naa AC? can be interfaced to 
?C-S/Rt43 by teaching, the pacicages the proper usage o:f t.he ACP. 



1.3.2 CIO Directive 



All user I/O is requested fay using the QIQ directive- The 
directive can be issued directly by a program or indirectly from 
the various run-time systems. 

The QIO directive together «ith the executive processing 
form the program I/O request component of RSX-llM. The RSX-llM 
executive is responsible for translating the QIQ requests into 
their internal representation (I/O packets)^ checking for 
Parameter validity, and dispatching the I/O packet to the 
correct processing routine. 

The device data bases are used by the executive to 
determine hoa a packet is to be processed. The executive may 
pass the function directly to a device driver or queue the 
packet to the driver I/O queue- If an ACP is mounted for the 
device, the packet is specially processed and sent to the ACP 
Instead of the device driver- It is extremely important to 
understand this mechanism when writing an ACP- 



1-3-3 Device Drivers 



Device drivers are the lowest level In the RSX-llM I/O 
hierarchy- Drivers provide the device service functionality and 
are small, responsive modules- RSX-llM device drivers do little 
more than physical data transfers and device manipulations- The 
driver I/O parameters are specified in a basic, often device 
dependent form- 

An ACP can interface to a device driver in a variety of 
ways- The most common approach is to use the normal QIO 
directive. An ACP will typically take the I/O request queued to 
it and issue device specific I/O requests to satisfy the 
request- The driver code itself is not aware that an ACP is 
calling it- 

Device drivers serve another purpose in Implementing ACP'^s- 
The driver mechanism is coavenient for extending executive 
processing- As sill be seen later, pseudo drivers can be 
implemented to provide the processing necessary for ACP I/O 
requests that is normally dona by the executive- The use of 
such drivers permits user-written ACP's to be implemented 
without modifying the kernel executive- 
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1.3.4 ACP'3 



Finally, ACP*3 are the component ahich iaplament device 
protocols. These tasks take I/O functions from the executive 
and perforai the desired operation according to the rules of the 
protocol. 



1.3.5 Suffliaary 



At this stage, a siaplistic visM of the RSX-llM I/O 
aechanisaj has been developed- The simplest case is a GIQ 
request from a task to a non-ACP device. The fioM is through 
the executive's QIO processor to the device driver to the 
device. 8y adding FCS/RM3, the task makes a subroutine call to 
the run-time library which then issues the actual QIO- The 
final case (Figure 1-1) adds an ACP to the device- Here, the 
I/O request is routed to the ACP by the executive- The ACP may 
issue its own I/O requests to the device driver or satisfy the 
request using its internal data bases- In some special cases, 
the executive may route the packet directly to the driver- 



1-4 ACP ABILITIES 



It is not often clear why ACP's are such a necessary part 
of the RSX-llM I/O mechanism- This section will discuss the 
abilities which are unique to ACP's and make them such a 
powerful application tool- 

The key abilities come fro® the fact an ACP is a task- 
ACP's are allowed to do things which are Impossible from device 
drivers- They can issue all the SSX-llM directives- For 
example, the ability of an ACP to issue QIQ's allows it to 
service a complicated I/O request by using the simpler services 
provided by a device or another ACP- 
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At the same tirae^ XCP's ace privileged tasks. The full 
abilities of the executive are available.- For axaiapie/ ACP's 
can allocate and return systeia pool !i 58 raly by saitching to 
system state and calling tne executive routines. In addition# 
as privilegad tasks# ACP's are mapped into the system pool and 
can examine and manipulate ail RSX-llM executive data 
structures- 

Also# because ACP's are tasks# they can be used with all 
the programming tools provided by RSX-llM. For example# they 
may use disk and memory-resident overlays# be checkpointed# and 
link to ODT. The last ability is a very key feature as it 
allows ACP's to be debugged much less destructively than device 
driver code. 

The executive Interface to ACP's also has abilities not 
normally available to device drivers. A feature of the 
interface allows ACP's to establish a mapping between several 
separate 1/0 requests. The process of opening a file# reading 
and writing disk blocks, and closing the file is an example of 
this mechanism. Sifflilarly# DSCSST supports establishing a 
logical link, transmitting and receiving data# and terminating 
the link. 

This feature allows an ”1/0 process" to be established for 
a logical unit in a task. Each process uses an ACP unique data 
structure called a window to establish the linkage between the 
lun and the operations being performed by the ACP. The window 
address is stored in the second word of the logical unit table. 
This address is passed to the ACP in the I/O packet and allows 
the ACP to reference the window when serving a request. The 
mechanism also includes support for notifying the ACP when the 
task terminates and I/O processes are still outstanding# even if 
the task has no outstanding I/O. 



1.5 ACP IMPLEMEMTATION 



This manual will cover three types of ACP implementations: 
standard# user# and foreign. ihlle each form fulfills the 
definition of "ACP“# standard ACP's follow the rules used by 
Digital in writing FllACP and MTAACP. Such ACP's are "known" to 
the executive ana special code is includad for their support. 

On the other hand# user ACP's are not "known" to the 
system# only to the device driver which uses their services. 
The major advantage of the approach is t.hat no changes to 
existing executive code are necessary for the user ACP# yet# all 
the advantages of having an AC? remain. 

Foreign ACP's are between standard and user ACP's. The ACP 
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is icnoan to the executive/ yet no special services are provided 
for support of the ACP. 

Throughout this paper, references will be made to the 
requirements for writing stancard, user, and foreign ACP's. In 
order to simplify the terminology, ”AC?” will be used when 
discussing material relevant to all styles. »OCP" (Digital 
Control Processor) will be used when refering strictly to 
standard ACP's. ”gc?« (Gser Control Processor) will be used for 
references concerned with the user form and "FCP" (Foreign 
Control Processor) will refer to ACP's which use the foreign 
feature of RSX-llM. 

The choice of writing a OCP, OCP, or FCP depends on the 
purpose of the ACP. The major difference between the various 
forms of ACP's is how and where the I/O requests designated for 
the ACP are processed. Mo matter which fora is impleaented, a 
certain amount of pre-processing Is required before an I/O 
request is received by an ACP- The next three sections examine 
how each form of ACP interfaces to the executive- 



1.5.1 DC P Approach 



Figure 1—2 diagrams the flow of an I/O request from an user 
task to a DCP. When a QIO is issued from a task, the directive 
dispatcher calls the entry $DRQIQ. The common QIO processing is 
performed first. The current task state is checked to see if 
the QIO can be issued at this time- If it can, the common QIO 
fields are checked for legality- Finally, an I/O packet is 
allocated from the system pool and initialized with information 
taken from the QIO directive parameter block.- 

Once the common processing is completed, the QIO processor 
dispatches to the function unique code. The current device 
status stored in the Dnlt Control Block (OCB) and the function 
bit masks in the Device Control Block (DCB) determine the type 
of function processing selected. In the case of an I/O packet 
designated for a DCP, the device driver must be loaded, the 
device marked as mountable, mounted, and not foreign, and the 
function marked as legal and ACP in the DCS mask fields. Mhen 
these conditions are met, the ACP special packet processing is 
invoked. Each I/O function supported by Digital ACP's is 
processed using special polish-driven routines- 
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One function of the special processing is to decide ahether 
the I/Q packet needs sequencing aith the- device driver state or 
ahether it can be queued directly to the ACP. If the packet 
does not need sequencing^ ORQIO queues the I/O packet to the 
receive queue of the AC? and schedules the ACP for axecution- 
Otheruise/ the packet is placed in the I/Q queue of the driver 
and the driver initiator is called. The packet uill be queued 
to the ACP Hhen it is dequeued by $GTPKT. This occurs 
transparently to the driver. 

I/O packets are queued to an ACP via the ACP task's receive 
queue. This is the same queue used by normal tasks to receive 
messages from other programs- The entries $SXRQP/$EXRQF in the 
executive queue the I/O packet and also cause the ACP to be 
scheduled for execution. 

In short, a DCP is knoan to the executive. Special code in 
the executive's DRQIO module handles functions designated for a 
OCP. The features of this approach are as follows: 

1. I/O functions processed by the DCP are marked as legal 
and ACP functions in the DC8 function masks. DCP 
function codes are required to be from 7-31(10). 

2. The device is marked as mountable, mounted, and 
not-foreign in the UCB- 

3- The I/Q packet is specially processed by DRQIO. The 
type of processing performed depends on the I/O 
function code and is done by the polish-driven routines 
in DRQIO. 

4. The I/O packet is queued to the DCP by the executive, 
however, for some functions the packet is queued 
directly by DRQIO and for others it is handled by 
GTPiiT. 



The DCP approach is appropriate for a user-written ACP when 
the new ACP processes current Digital ACP functions. In this 
case, no modification of the code in the executive is necessary 
to support the user-written ACP- It is also important to 
understand the DC? approach when using the methods discussed in 
the next two sections. The FCP and OCP approaches are not 
short-cuts, they merely move the special processing performed in 
ORQIO to outside the executive. 
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1.5.2 OC? approach 



The 3CP' approach pro via as ail the f-uactionaiity found in 
Oigltal's ijapleaentatioh of aCP's. The approach uses features 
of the RSX-llM I/O mechanisia to aove the special code for ACP 
I/O processing to outside the executive. This permits a user to 
Hr its a totally nea ACP Hlthout modifying the executive. 

The key to the UC? approach Is the OC.QUS bit in the UC3- 
Mhen this bit is set, 1/0 packets are not queued to either the 
device driver or any associated ACP. Instead, the driver 
initiator is called directly from the DRQIO module. The driver 
can then perform any necessary special packet processing in-line 
Hith the executive's I/O processing. Mhen finished the driver 
is responsible for placing the I/O packet in the correct queue. 

The fact that no context switch can occur betaeen the 
executive and the call to the device driver is critical to the 
UCP iaplefflentation. Certain types of processing done on the I/O 
packet, such as address checking and relocation, must occur in 
the context of the task ahich Issued the I/O request. Once a 
packet is placed in driver or ACP queue, a context suitch may 
occur before it is retrieved. In the case of a packet queued to 
an ACP, a context switch is implied by the fact that the ACP 
must be scheduled. 

Figure 1-3 illustrates the flow of an I/O request from an 
user task to a UCP. First, the common QIQ processing occurs. 
The first difference between a DCP and UCP is evident when the 
dispatch is made to the function unique code. The UCP approach 
marks all functions serviced by the UCP as legal and control 
functions. By marking the function as a control function, the 
executive merely copies the six GIO parameters to the I/O 
packet. This avoids any special processing built into the 
executive for DCP-style ACP's. 

Once the I/O packet is constructed, the driver initiator is 
called without any queueing, due to UC.QUE being set. The 
driver can then process the I/O paraiBeters In the I/O packet as 
needed. The driver then queues the packet and requests the OCP 
by calling the normal ACP scheduling routine. If the packet 
should not be routed to the UCP, the driver queues the packet to 
itself and calls $GT?KT to correctly synchronize driver packet 
processing. 




ACP PHILOSOPHY 



PAGE 1-13 



i 1 

i Task Code i Task 

j 

1 

1 CTL QIO 

i 

\i/ 

I — — j 

I Check for Legality 1 

1 Construct I/O Packet ! $ORaiQ 

I Copy I/O Paraiaeters } 

I 

I JMP 
I 

\U 

j j 

i Call Driver Initiator J $ORQRQ 

I * 

1 JSR 
I 

\|/ 

I 

I Special ACP Processing I 

I 1 Device Driver 

I Queue to ACP I 

I 

1 osa 
I 

I 

I Queue Packet to TCB I 

i i $BXRQP 

I Request ACP 1 

I— , 



Figure 1-3 
OCP FLOM 




ACP PeiLQSCPeY 



PAGE 1-14 



Therefore/ an OCP is IcnoHn to the device driver. The 

executive is unaware that a OC? is being interfaced to the 
driver. This has the disadvantage of generally limiting a OCP 
to supporting only one device driver. The features of the UC? 
approach are as folloas; 

1. The I/G functions processed by the UCP are marked as 
legal and control functions In the DC8 function masks. 

2. The device is typically mariced as mountable# mounted# 
and not-forelgn in the OCB- The driver is also set for 
no queueing of the I/O packet (0C.QU£=1)« 

3. The I/O packet is processed as a control function by 
DRQIO. Any special processing required by the UCP is 
performed in the device driver. 

4. The I/O packet is queued to the OCP by the device 
driver «hen it finishes its special processing- 



1.5.3 FCP Approach 



The FCP approach is betaeen the DCP and UCP techniques. 
The approach is based on the RSX-llM y3.2 executive's support of 
the foreign ACP bit in the UCB fUS.FOR). When this bit is set# 
the special processing applied to DCP functions is bypassed. 
The I/O parameters are merely copied to the I/O packet. 

Figure 1-4 shous the flow of an I/O request to a FCP. 
Functions to be routed to the FCP are marked as legal and ACP 
functions in the OCB function bit masks. The device state in 
the UCB must be mountable# mounted# and foreign ACP. When these 
conditions are met# the QIO parameters are copied without any 
checks to the I/O packet. This is the same as the processing 
applied to a DCP. At this point# the I/O packet Is routed to 
the FCP by DRQIO if the queue disable bit is not set (UC. QOE). 
This is acceptable only if no special processing needs to be 
applied to the packets. 



If this condition cannot be met# the same approach used for 
OOP's must be applied. The packet must be passed without 
queueing to the driver initiator wnich then applies any special 
processing needed. When completed# the driver can either queue 
the packet directly to the FCP or queue it to itself and let 
$GT?!(T dequeue the packet and send It to the FCP. 

While FCP's are known to the executive, the same processing 
is applied no matter what the 1/0 function. The following is a 
summary of the FCP approacn: 
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Tlie I/O functions processed by tne FCP are mackad as 
legal and AC? functions in the OCB function masks. 



2-. The device i.s marked as momi table#' mounted# and foreign 
in the UC3. Any necessary special packet processing is 
performed by the device driver and the queue disable 
bit (UC-QUE) must be set- 



3. The executive only copies the QIQ paraaeters to the I/O 
packet. As stated above# any special processing is 
must be done by the device driver 

4. The I/O packet can be queued to the FCP by DRQIQ# the 
device driver# or GTPKT. 



The advantage of the FCP over the UCP approach is not in the I/O 
packet processing. The executive services are minimal and like 
all Digital softaare# subject to change. The advantage is the 
support provided by the MOO and OHO task for mounting and 
dismounting the foreign ACP. 



1.6 ACP APPLICATIOMS 



ACP's can be written for a aide variety of applications. 
One type of application is a non-Flles-11 file system# 

particularly, if the ACP Is interfaced to FCS/8MS for 
device/ file independence. T«o examples are listed belo«2 

1. If a site supports mixed systems (RT-11 and 8SX-11M for 
example)# an ACP could be implemented to support the 
foreign file structure. If interfaced to FCS# the 
RSX-llM utilities could be used to access the foreign 
disk directly. 

2. If a site has a raquirement to process foreign 

magtapes# an ACP could be written for this task. This 
is basically what occurred when MTAICP was introduced 
by Digital. 



ACP's could also be used to implement communications 
protocols. Digital took this approach with DECNET. A 

user-written ACP could be used to coaimunicata with other 
computars via some established protocol (SYSYf^C# 3DLC# etc.) or 
a site— specif ic protocol. Alternatively# an ACP could be 
written to replace HSP within the OSCMET architecture. This ACP 
could implement a specialixed link level protocol. 

Another class of applications is be to extend the 
functionality of a current Digital device. For example# one 
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method of implementing transparent line printer spooling HOiiid 
be via a line prinrar AC?, ‘mis task aouid ■ intercept write 
requests to the line printer and output thea to a disk file, 
i'hen the output is terminated/ the file is queued to the 
printer. 



ACP's can also be used to solve application probleas. For 
example, an application system may use a complex file 
organisation for storing and retrieving data- Usually with such 
Implementations, special subroutine libraries have to be 
developed and linked to each task to access the information and 
coordinate updating the dhta- An ACP could be written that 
would essentially iraplemant a special database management system 
for the application- 

Many other applications for ACP's could be listed. 
Appendix F list various user-written ACP's that have been 
reported to the author- Other users who have written ACP's are 
invited to submit a summary of their implementation to be 
included in future versions of this manual- 
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DATA SIR OCT ORES 



ACP's, like most system tasks, deal with the RSX-llM system 
data structures. In the case of ACP's, some of the data 
structures are Integral to the ACP concept. This chapter 
examines the RSX-llM data structures in the context of ACP 
usage. The emphasis is on the global relationship betyeen the 
data structure, the RSX-llli I/Q mechanism, and the ACP. 
Appendix B presents a detailed view of the data structures 
mentioned in this chapter. 

The data structures of interest to ACP's can be divided 
into seven categories: QIO data structures, device driver data 
structures, common ACP data structures, ACP specific data 
structures, ECS data structures, RMS data structures, and other 
structures- This chapter deals with the first four areas- The 
FCS and RMS structures are discussed in Chapter 4. This chapter 
will also touch on the how some of the other data structures are 
used by ACP's- 



2.1 QIO DATA STROCTBRES 



The QIO data structures are used to package the I/O 
requests and route the request to the correct device- The data 
structures used to package I/O requests are the QIO directive 
parameter block and the I/O packet- The QIO directive parameter 
block is formed in the issuing task- The I/O packet is the 
executive representation of this structure- The data structzire 
used to route I/O packets, to the correct dearies is the logical 
unit table. This table is found in the task header and is used 
to map a logical unit number to a specific device. 
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2.1.1 QIO Directive Paranietac Block 



The QIO directive paraneter block (0P8) is the foris an I/O 
request takes in a user task. The block is normally cons true tad 
by the QIQ$ and macros- All I/O requests/ including 
requests to ACP'S/ are issued from a task by using the QIQ$ and 
QICW$ directives- 

ihile the format of a QIO DPS is constant/ some special 
consideration must be given the DPB uhen writing a new ACP. The 
AGP design must consider the I/O functions it will service and 
the format of the six QIO parameters. 

The I/O function is a two byte field. The executive only 
considers the high byte in processing an I/O request. This byte 
is the function code and has a legal range of 0-31(10). The low 
byte is the subfunction field. All values are legal for this 
byte. The subfunction codes are used by drivers and ACP's to 
further delimit I/O functions. The only requirement for the 
subfunction code is that all sufafunctions of a particular 
function code must be the same type of request (transfer/ 
control/ etc.). 

Some rules also apply to the function code byte. Some 
codes have been traditionally reserved for special I/O 
functions; in particular/ codes 0-7 all have traditional 
meanings and should not be considered for new ACP I/O codes. 
Also/ if the new ACP follows the DCP implementation/ the 
executive $GTPKT routine requires the ACP function codes to 
range from 7-31(10). 

Because the I/O parameters for an ACP function are usually 
processed specially/ there . is almost complete freedom in what 
parametars are used. The only RSX-llM requirement applies to 
transfer functions- For such I/O requests, the executive 
expects the first parameter to be the address of a buffer and 
the second paraaeter to be the size of the buffer in bytes. 



2.1.2 I/O Packet 



The I/O packet is the internal representation of an I/O 
request. ORQIO allocates the I/O packet from system pool and 
Initializes it with values' taken from the QIO directive 
parameter block. the packet is then queued to the appropriate 
driver or AC? for servicing. 

When writing a new ACP, the process of initializing the I/O 
packet parameter fields must be considered. For DCP's, this is 
the main purpose of the special ACP code in ORQIO. A typical 
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AGP I/O r surest laay pass several addresses and special 
parasetajcs.- Each address . must- be ■ checked and raiocated befor e 
stored in the packet. In soaa cases#- the parameters passed t 
the ACp have little physical resemb lance to the original ’ll 
parametars. The special ACP processing has repackaged th 
information for the ACP. 

The rest of the I/O packet is typically of no interest to 
ACP's, aith tiio exceptionsj the function code and the address 
of the second lun word. The executive copies the function code 
from the aiO directive parameter block into the I/O packet- The 
function code can then used by the ACP to dispatch the packet to 
the appropriate function processor. 

The second lun word address field Is the one part of the 
I/O packet which is not typically used by device drivers- This 
location contains the address of the second word in the logical 
unit table entry for the lun of the I/O request, (see next 
section). The importance of this word will be explained in the 
Section on window blocks- 



2-1-3 Logical Unit Table 



The purpose of the logical unit table (LUT) is to map 
logical unit numbers to devices- The LUT table is also used to 
map luns to I/O processes. The table is a portion of the task 
header and consist of a two word entry for each possible logical 
unit a task may use- The size of the table is fixed at 
taskbuild time by the UNITS option. 

TK3 fills the table with the ASCII device name and unit 
number- When a task is installed# the first word of each entry 
is replaced with the device UCS address and the second word is 
zeroed- ahen an I/O request is issued# the logical unit number 
maps the appropriate entry in the LOT. Any redirect pointers 
are followed and the I/O packet is dispatched to the resulting 
device. This may result in the packet being queued to an ACP 
serving the device- 



The second word of the LUT entry is used by ACP's to map 
I/O processes to logical unit nuabers- The address of the 
window block is kept in this word. A window block is the l/Q 
process unique data structure ana is discussed in a latter 
section- An exaapia of window blocks is the FllACP window 
blocks used to map virtual blocks to logical blocks. Note# an 
AC? window block' is different from a ?LAS or task mapping 
window. 



The second LOT word has two other uses important to ACP's- 
Blt 0 of the word is the lun lock bit- Mhen this bit is set. 



^ a a 
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tha executive prayents tne user task from issuing any QIG's for 
the logical unit. This can be used by ACP's- to insure proper 
synciironi ration between a request it is currently servicing and 
the user task. 

The other use of the second LUT word is to notify ACP's 
when a task exits with outstanding I/O processes. A task is not 
permitted to exit until all second LOT words in the logical unit 
table are zero. When a non-zero entry is found, tha executive 
queues a special I/Q request to the ACP. The AC? is responsible 
for terminating the I/O process and zeroing the second LOT word. 



2.2 DEVICE DATA STRUCTURES 



The device data structures are used to describe the generic 
device type, each separate device, and each hardware controller. 
The Device Control Block (DCS) names the device and contains the 
I/O dispatch tables. There is one DCS for each device type. 
The Unit Control Block (OCB) contains the information for each 
device unit- The Status Control Block (SC3) Is used to 
coordinate activity among device controllers- There is one 3CB 
for each controller. The RSX-llM executive typically permits 
only one I/O request to be outstanding for each controller. If 
the controller supports multiple units (OCB's) but requires 
serial access, one SCB will be used for all OCB's. If the 
controller permits multiple access, one SCB will be allocated 
for each UCB. 

Most of the information In the device data structures is 
specific to the needs of device drivers- A CP's are usually only 
concerned with a few fields. The next three sections comment on 
how the DCB, UCB, and SCB are involved with ACP implementation. 



2.2.1 Device Control Block 



The Device Control Block (DCB) names the device, points to 
the device unit structures and controls how I/O functions for 
the device are processed. This last feature is important to ACP 
impleasentation. The DCB function masks decide whether a 
particular I/O function is legal or invalid. They further 
classify legal functions into four types: control, noop, ACP, 
and transfer. Mhan impiaaentiag a DC? or FCP, functions which 
should be routed to the AC? are raariced as legal and ACP in the 
DCS function masks. This causes the special packet processing 
in ORQIQ for ACP functions to be invoked. Mhen implementing a 
UCP, the functions are marked as legal and control- 
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2.2.2 Onit Control Blocic 



The Unit Control Block (0C3) is the key device structure. 
There is one UC3 for each separate device. The UCB's are the 
one device structure that are variable In length. The only 
requirement for UCB's is that all UCB's belonging to a DCS be 
allocated contiguously and that ail are the same size. 



When a device supports an ACP, the UCB's are extended at 
least two words beyond the normal length. These additional 
words are used to hold the Task Control Block address of the ACP 
(U.ACP) and the Volume Control Block address (O.VCB). The 
address stored in O.iCP is the task TCB address the executive 
will use when queueing ACP I/O packets- 

The flag fields in the UC8 are also of interest to ACP's. 
The control flags byte (U.CTL) are used to decide how various 
I/O requests are to be handled. One bit in this field is the 
OC.QUS bit used by UCP and FCP implementations to pass the I/O 
packet to the device driver for ACP processing. The unit status 
flags byte (U.STS) contains bits which define whether the unit 
is busy (OS. 8S¥), mounted (US.MNT)/ foreign (OS. FOR), or marked 
for dismount (US.MDM). The correct manipulation of all of these 
bits is necessary for the correct operation of an ACP. A device 
is marked busy whenever an I/O function is dequeued for the 
device driver. The busy bit is cleared whenever an I/O function 
is completed by calling $IODON. A function will not be dequeued 
for a device if it is marked busy. Because ACP functions are 
not processed by the device driver/ the driver Is not marked 
busy when an ACP function is dequeued and passed to the ACP. 
This allows the driver to continue to service functions and 
requires ACP's to not clear the busy bit when they finish an I/O 
request. The mounted bit signifies an ACP is mounted for the 
device and can process I/O requests. Mhan an device is marked 
mounted/ U.ACP and U.VCB are assumed to contain valid values. - 
The OS.MDH bit signifies a dismount request has been made for 
the unit. Ho new I/O processes should be allowed to start and 
when all outstanding processes are completed/ the ACP should 
mark itself not mounted by setting OS. MOO. The ACP exits when 
all devices are finally dismounted. Finally/ the 03-F0R bit is 
the Indication to the executive that the foreign ACP logic 
should be invoked. 



2.2.3 Status Control Block 



The Status Control Block (SCB) Is used to define and 
control access to the hardware controller. ACP's are usually 
not concerned with this data structure unless they are closely 
coupled to the device driver. 
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2.3 ,\C? Ca?«OM DATA STRUCTURES 



Tao data structures are cosaaon to all ACP"s:. ’/oi'uaa 
Control Siocics and «i.ndo« Slocks. Tiia folume Control Slocks are 
used to hold information about each separate device an ACP 
services. The Mindow Slocks hold the I/O process information. 
While all ACP's typically use these structures/ their format is 
AC? dependent- 



2.3.1 Volume Control Block 



One feature of ACP's is their ability to service several 
different devices. The data structure used to keep the 
information for each device is called a volume control block 
(7C8). A VCB is allocated from the system pool uhen an ACP is 
mounted for a device. The address of the VC8 is stored in 
offset U.yCB of the device UCB. The VCB is returned to the pool 
when the ACP completes dismounting the device. 

The length and format of a VCB is ACP-dependsnt. Only the 
first word has a common meaning across ACP's. This word of the 
VCB is the volume transaction count and is used as a counter of 
the number of outstanding I/O requests queued to the ACP for the 
device. It also counts the number of I/O processes created by 
the ACP for the device- The ACP cannot dismount the device 
until the transaction count reaches zero/ indicating no activity 
for the device. 

For DCP and FCP implementations/ the executive increments 
the transaction count ahensver it queues an I/O packet to the 
ACP- It is the responsibility of the device driver to increment 
the transaction count uhen it queues a packet to a OCP. The ACP 
is then responsible for decrementing the counter when it 
completes an I/O function and incrementing and decrementing the 
counter uhen it creates and destroys I/O processes- 

The remainder of the VC8 can be used for any purpose 
desired by the implementation. The typical information kept in 
a VC8 is any data uhich is unique to the volume. For example/ 
FllAC? keeps the index file mapping information and volume 
defaults in disk VCS's- 



2.3.2 Windou Control Block 



As mentioned before/ one powerful feature of ACP's is their 
ability to establish a mapping betueen I/O requests- For 
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example, FllACP maps read and air ite virtual block I/O to logical 
aisk blocks- The inf oraiation necessary to do this mapping is 
established when the fils is opened- 

ihis ability to craata an. ’”,1/0 process** uses a data 
structure called window blocks- These structures are cofflpletely 
ACP dependant in length and format and contain whatever 
information the ACP needs to keep for each separate process. 
Typically, window blocks keep access masks, pointers to other 
ACP unique data structures, and retrieval information for read 
and write requests- 

Mindow blocks are allocated by the AC? when it creates an 
I/O process- Mhlle the window block is typically allocated from 
system pool, it can be allocated from the ACP task space If only 
the ACP accesses the window- The window block address is stored 
in the second word of the logical unit table entry. This 
address is passed in the I/O packet in offset 1.LN2. Further 
I/O requests from the same logical unit will always reference 
the same logical unit table entry, allowing the ACP to retrieve 
the window block address. 



NOTE 

The address of the second LUT word cannot be kept 
internally by the ACP. The LUT table is located in 
the task header, which is destroyed and reallocated If 
the task is checkpointed. An ACP cannot depend on any 
location in the task header being the same across I/O 
requests. 



2.4 ACP SPECIFIC DATA STRUCTURES 



ACP's also can create their own data structures. For 
example, FllACP creates File Control Blocks (fCS) for each open 
file. The type and extent of data structures created by a 
user-written ACP is one of the keys in the ACP design- 

Ona guideline to AC? specific data structures is to 
aini.mlzs the usage of system pool- Any information used only by 
the ACP should be allocated first from an internal ACP pool and 
overflow to system pool only if allocation fails- One way to 
miniaiiza system pool usage is to use the window block to point 
to the internal ACP data structures, allowing I/O process 
structures to be mapped on a process basis instead of keeping 
all information in the window block- Similarly, volume control 
blocks can point to information in the ACP pool which is used 
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only by tne AGP. 



2.5 OfHSH DATA STRUCTURES 



The structures mentioned so far are the key structures to 
ACP's. Other structuras an AC? may need to use include the Task 
Control Blocks (TCS), task headers/ and Partition Control aiocks 
(PC3). Depending on the application/ any and all RSX-llH data 
structures may be used by an ACP. 

One important structure to an AC? is its oan TCB. An I/O 
request is queued to an ACP fay placing it in the ACP receive 
queue. The ACP dequeues the I/O packet by getting its TCB 
address and removing an entry from the receive queue. The 
technique for this operation will be shoan later. 




CHAPTER 3 



AC? CHECKLIST 



ACP laplementation is a paradox. ACP's are integrally 
coupled to the executive. It appears that a comprehensive 
knouledge of the RSX-llM design philosophy^ data structures^ and 
executive code is needed to implement an ACP. Houever^ after 
implement ing an ACP, it is obvious that the coupling to the 
executive is loose, logical, and straightforward. It is simple 
to interface an ACP to RSX— IIM; any difficulties come from the 
internal ACP design. 

This chapter aalks through the design of an UC?-style ACP. 
In order to keep the emphasis on the executive/ACP interface, 
the example ACP serves no useful function. Rather, the ACP 
merely demonstrates the functionality available to an ACP. The 
chapter emphasizes the empirical rules that apply to ACP design- 
Later material will develop the rationale for the logic 
presented here. 



NOTE 

Included aith the distribution of this manual are the 
sources for the sample ACP, its associated driver, and 
the enable and disable task. It would be useful to 
obtain a listing or the sources and refer to them when 
studying this material- 



3.1 giO DESIGN 



uie first step in AC? design is to decide ahat I/O services 
the ACP will provide, it is assume tha nature of the services 
needed is known; these fall out of the reasons an ACP is the 
chosen solution. This section deals with selecting the I/O 
function codes to be used, the format of the I/O parameters for 
each function, and what relationships will the user I/O requests 
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aava to each other- 

The exaraoie 4CP supports five user functions- The first 
function creates an I/O pcocass- Another function tariainates 
the process, Tao other functions perforni input and output to 
the process. The last function is a control function to a 
created process. The sample ACP services the requests fay 
outputting a message to the console terminal that the request 
Has processed and returns success. The driver serviced by the 
ACP supports tHo I/O requests/ read and arite logical block. 



3,1.1 Function Code Selection 



The choice of I/O function codes is fairly straightforward. 
If the ACP is emulating FllACP for a new device# the Files-11 
QIO functions will be used. If the ACP will provide unique I/O 
services/ new QIO codes should be chosen- 

The latter is the case with the sample ACP, It is 
advantageous not to redefine existing I/O codes because this 
could have undesirable effects if I/O is directed to the wrong 
device. For the sample ACP# the I/O function code 31(10) will 
be used for all user requests. The advantage of using this 
function code is that it is the least used by Digital device 
drivers and is not used by any Digital ACP. The function 

modifier field will be used to differentiate the separate 
requests. The following codes will be assigned: 

IX.CRE 037/000 Create process 
IX.CLO 037/001 Terainate process 
IX. PUT 037/002 Output to process 
IX, GST 037/003 Input from process 
IX.CTL 037,004 Process control 



ACP's also typically service ACP control functions such as 
mount and dismount ACP/ and abort process. The sample ACP will 
use the traditional I/O function codes for these services: 

lO.MOU 005,000 Mount ACP 
lO.OMa 006/000 Dismount AC? 

IQ,CLH 007/000 Abort I/O process 

The 10, MOO and IQ.DMQ symbolics are not defined by , Digital, 
However, tradition has used these symbolic names and values as 
local definitions. The lO.CLK symbolic is defined and the value 
must be associated with this function. 

Finally, the function codes for the driver must be chosen. 
For the sample driver, the traditional read and write function 
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codes are used# IQ-RL3 and I0» iCB. 



3.1«2 I/O Parameter Selection 



The next step In designing the QIO's is to decide on the 
ioraat of the I/O parameters to be used for each I/O request. 
Because ACP functions are processed uniquely^ you have almost 
complete freedom in this area. However/ the ACP and driver 
implementations will depend heavily on the choice of I/O 

parameters and the format chosen for each I/O request. This is 
a critical area in the design process. 

The parameters for the sample ACP I/O requests have been 
chosen mostly to reflect some of the more common features fomd 
in ACP parameter processing- The following is the format for 
each request. In order to keep the logic simple/ the same 

parameter format is used for each I/O function. The only 

difference between functions is whether a particular parameter 
is required or not present (zero) for the function. 

Parameter #1 - If present/ the parameter is the output 

buffer address. Byte alignment is allowed for the 
buffer 



Parameter #2 - If parameter #1 is present/ this parameter 
is the size of the output buffer in bytes. The size 
may be byte aligned. 

Parameter #3 - If present/ the parameter is the input 
buffer address. Byte alignment is allowed for the 
buffer. 

Parameter #4 - If paraaetar #3 is present/ this parameter 
is the size of the input buffer. The size may be byte 
aligned 

Parameter #5 - If present/ the parameters is the access 
control value- The parameter has legal values from 0 
to 3. A zero indicates no process I/O is allowed. A 
value of one indicates IX-POT functions are allowed 
and a value of two indicates IX. GST functions are 
allowed- A value of three allows both type of orocass 
I/O 

Parameter #6 - This parameter is never user and must always 
be zeco- 

The following table maps what I/O parameters are required 
(R) and illegal (blank) for the five ACP I/O rsquestsi 
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I/Q Coda I PI I P2 j ?3 } P4 1 P5 i P6 \ 

1 — f: 1--., I 1 1 1 

IX.CRE 1 1 I I ! R 1 1 

j 1 1 ^ 1 1- 1 

IX.CLQ ! J i I i i I 

1 1 1 1 — -I i— j 

IX. POT i R ! R } 1 1 i 1 

j 1 1 1 j I 

IX. GST I ! I R I R r I 1 

} 1— j 1 i-^ ! 

IX.CTL I i I I 1 R I I 

-j 1 1 1 j j 1 



3.1.3 Relationship Betaeen I/O Requests 



The final step in QIO design is to decide the relationship 
between I/O requests. The typical requests serviced by an ACP 
have relationships defined by the I/O process. For example/ it 
would be Illegal to perform an input before the I/Q process is 
established. The general rules that must be applied to each ACP 
I/O request are as foilowss 

1. Must the ACP be mounted to service the request? This 
rule applies to all functions serviced by the ACP. I/O 
request serviced by the driver may be allowed if no ACP 
Is mounted. If an ACP is mounted/ I/O requests 
serviced by the driver may only be allotted from 
privileged tasks. 

2. Must the ACP not be marked for dismounting to service 
the request? If an ACP is marked for dismounting but 
has not yet completed the dismount/ no new I/O 
processes should be ailowad. However/ all current I/O 
processes should be allowed to run to completion. 

3- Must an I/O process be established to service the 
request? This rule applies to functions which the ACP 
will map to an I/O process. Typically/ input/ output/ 
and terminate process functions cannot be serviced 
until the I/O process is established. 

4. Must an I/O process not be in effect to service the 
request? this is the reverse of the above rule. A new 

process cannot be created until the previous process 
has tsraiaatad. 



Any other rules that make sense for your design may be 
applied- In the case of the example ACP/ the only special rule 
applies to the IX.PUT and IX.GET functions. Mhen the process is 




ACP CHECKLIST 



PAGE 3-5 



created using the IX-CRE function^ pacaiaetec #5 specifies the 
type of process I/O ailoyed. ( see section: 3-l»2)w. The- access 
parametec can be changed by the IX. CTL function. 

The following table suMarizes how the four coason rules 
listed above (Rl-fi4) and the one special case rule (SC) are 
applied to each ACP function. An entry of **A” means the rule is 
applied. Other wise, the particular rule does not apply to the 
function. 



I/Q Code I fil I R2 ! R3 | R4 1 SC J 

1 1 1 j j 

IX.CRE I A 1 A 1 I A I 1 

1 }-— i 1 j 1 

IX.CLO I A I J A J I I 

1 1 , J J 

IX. PUT 1 A 1 I A I I A i 

j 1 1 1 J J 

IX. GET 1 A I ! A I I A I 

1 J -I } 1 — 1 

IX.CTL 1 A I I A I I 1 

1 J J J 1 



3.2 DEVICE DATA BASE OESIGM 



After it is determined how a user program Hill interface to 
the ACP/ the next step is to add ACP support to the device data 
structures. This is a simple step. The basic structures 
documented in the Guide to Mriting an I/O Driver manual still 
apply. Adding ACP support to the driver merely involves setting 
up some of the fields not normally used. 

Only the device control block and unit control block need 
to be considered uhen adding ACP support to a driver. The 
status control block (SCB) is strictly driver related. 



3-2.1 Device Control Block 



The Device Control Block (OCB) is used to name the device 
and control the axacutive processing of I/O packets- For an- AC? 
supported device/ the docuaen tation on pages 4-7 to 4-iS of the 
Guide to Mriting an I/Q Driver applies. The additional step 
necessary for the support of the ACP is to decide on how the AC? 
functions Hill be processed and therefore/ how the DCS function 
masks should be set up. 



If a DCP or FCP style ACP is being implemented/ the 
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functions dasigaatad for the AGP will be isarkad as ”lagai and 
AGP” in- the aiask field. If a UCP is being iisplaaientad^:. the 
functions will be aarkad as ’'legal and control”. 



The following snows ho« the OCB function njasks are set up 
for the sample AGP. Mote ho« the IQ.RL3 and 10. MLS functions 
are marked as legal only^ implying that the functions are 
transfer functions and will be handled by the driver. The 
IX.??? functions are marked as "legal and control”. Also note 
that the special IQ.CLM function Is marked as "legal and 
control" but the mount and dismount requests are not Included in 
the DCB masks. These functions are queued directly to the ACP 
by the enable and disable tasks and are not processed by the 
executive. 



.WORD 


000206 


)Legal 


(IQ.CLM/ 


.WORD 


000200 


^Control 


(lO.CLN) 


.WORD 


000000 


/No-op 




.WORD 


000000 


;ACP 




.WORD 


100000 


/Legal 


(IX.???) 


• WORD 


100000 


/Control 


fix.???) 


-WORD 


000000 


;Mo-op 




-WORD 


000000 


;ACP 





IQ.RL8) 



3.2.2 Unit Control Block 



The Unit Control Block Is the key structure as far as ACP's 
are concerned. The basic OCB design is documented in the Guide 
to Writing an I/O Driver Manual (pages 4-19 to 4-26). The 
fields in the 0C3 that must be properly set up for ACP's are as 
follows: 

U.CTL - Unit Control Masks- The bit masks in this field 
will typically be set up for the driver's 
requirements- The one bit which may be turned on 
for ACP support is UC.QUE. This bit tells the 
executive to call the driver with the I/O packet 
without queuing first- This is the mechanism used 
for FCP and UCP style ACP's that allows the driver 
to specially process the AC? I/O packets- 

U.STS - Unit Status Masks. Some of the bit masks in this 
field are used to mark- whether an AC? is mount -ad# 
foreign# and/or marked for dismount- The fisid 
will be initialized as not mountsd {nS-MMT=l) for 
ail ACP'3 and foreign (US-PQR=1) for FCP's- The 
AC? is then responsible for properly handling the 
states of these bits and the marked for dismo\jnt 
bit (US.MDM). 
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MOTE 

T.he sense of the 0S»M1T mask is opposite 
to most maslcs. The bit is sat if the AC? 
is not mounted and cleared afiien the iCP 
is mounted^. 



(J.Ck'l - Oevice Characteristics lord #1- The word contains 
bit masks which define the device characteristics. 
The masks are used by RSX-llM to properly handle 
different devices. For example^ FCS uses this word 
to decide whether disk or terminal I/O is being 
performed. 

For ACP's, the D?.MNT bit signifies that an ACP can 
be mounted for the device- The DV.COM and DV-Fll 
bits are used by RSX-llM MQU and DMQ tasks to 
decide what ACP should be mounted- If a DCP is 
being implemented^ the characteristics that apply 
to currently supported Digital devices should be 
used for the new devlce/ACP- 

If an FCP or DCP is being implemented^ only DV.MNT 
needs to be set- In addition^ the low byte of the 
word should be set to accurately reflect the nature 
of the device itself- A description of the bit 
masks for the O-CMl field can be found in Appendix 
8 . 

D-ACP - ACP TCB Address- This word is an extension to the 
normal UCB used by RSX-llM- The word must be 

allocated for devices which are connected to ACP's 
and follows the U.CMT field- khen an ACP is 
enabled^ the word will contain the address of the 
ACP's Task Control Block. This the the TCB the I/O 
packet will be queued to when it is sent to the 
ACP- 0-ACP is initialized when the ACP is enabled. 

0-VCB - Volume Control Slock Address- This word is also an 
extension to the normal DCS and follows U-ACP- The 
word contains the address of the volume control 
block. It is initiailzad whan the AC? is enabled- 

The following, coda- segment is the UCB for the example- 
davica- The values are set for a UCP-styla AC? implementation- 
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,IF DF MS$jlUP 

.40RD ' 0 . MH.aMM ) QliNIMG rSRMIML UC3 AOORSSS 

.ENOC 

-AGO: : 

.MQRD 
• 'd ORD 
.BYTE 
.BYTE 
.BYTE 
.BYTE 
.I^ORD 
. ORO 
.WORD 
.MORD 
.WORD 
.WORD 
.WORD 
.WORD 
.WORD 
.WORD 



3.3 ACP DATA BASE DESIGM 



The final step in the general ACP design is the AC? 
specific data bases- Here/ the ACP implementation has complete 
freedom as R3X-11M imposes very few rules. 



3.3.1 Volume Control Block 



One data structure common to all ACP's is the volume 
control block. This structure is allocated from the system pool 
when an ACP is mounted for a device. The VCfl is linked to the 
UCB by storing its address in U. ¥C8. 

The ¥C8 is used to hold all unit specific information for 
tne ACP. The ACP pnilosopriy allows seyreral devices to use the 
same AC?. Typically^ the ACP treats each device as an 
independent entity; therefore^ a separata data Oase is need. 
The ^ca serves tais purpose. 

The length and format of VCB's is ACP dependent. Only the 
first word has a common usage. This is the transaction count 
and is used to count tne number of outstanding I/O requests and 
processes for the device. When the VC3 is allocated^ this word 



;RSF. LABEL. 



.ACDC3 


?(U.0C8 


) 


POIHTSR TO DCS 


.-2 


;((J.R£0 


) 


REDIRECT UCa POISTS.R 


DC . QUE 


;(U.CTL 


) 


COMTRQL FLAGS 


OS.MWT 


;(a.STS 


) 


STATUS FLAGS 


0 


XU.UNIT) 


UNIT HUMBER 


as. RED 


;(a.STS2) 


STATUS FLAGS 


DV.MMT 


;(u.c«i 


) 


DEVICE CHARACTERISTICS 


0 


XO.CM2 


) 


DEVICE CHARACTERISTICS 


0 


;(U-CW3 


) 


DEVICE CHARACTERISTICS 


1000 


;(0.CW4 


) 


BUFFER SIZE 


$AC0 


;(a.sc8 


) 


3C8 POIHTER 


0 


Xa.ATT 


) 


ATTACH WORD 


0,0 


X0.30F 


) 


buffer RELOCATION ADDRESS 


0 


xa.csT 


) 


SUFFER SIZE (BYTES) 


0 


JfO.ACP 


) 


ACP TCB ADDRESS 


0 


5(U.VC3 


> 


VC8 ADDRESS 
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should be zeroed. 



3.3.2 WiadOM Block 



The other structure comaon to aost ACP's is the alndow 
block. This structure is completely ACP dependent and need not 
be even allocated from pool. Window blocks are the structures 
used to keep I/O process-dependent information. The window is 
allocated when the process is created by the AC?. The address 
of the window is stored in the second LOH word of the LOT table 
for the task which issued the I/O request. The LOT table 
address can then be retrieved from future I/O packets from the 
same lun/ and from it, the window address. 



Window blocks contain whatever information is needed by the 
ACP to map the individual I/O request to the I/O process. For 
example, FllACP windows contains the mapping information between 
the logical blocks of a file and the physical disk blocks. 
Window blocks also typically point to other data structures used 
by the ACP and fora the key structure for the I/O process. 



3.3.3 Other Data Structures 



Finally, ACP's may create new data structures. Any ACP 
implementation should keep the system pool utilization to a 
ffllnifflum. One method of accomplishing this is to use an ACP task 
pool for the structures used only by the ACP and overflow into 
the system pool only when the internal pool is exhausted. The 
yCB and window blocks, which are usually in the system pool, are 
kept short and point to the new data structures. This technique 
is used by FllACP for File Control Blocks. 



3.4 DEVICE DRIVER IMPLEMSST AXIOM 



Once the design of the QIO requests and data bases is 
finished, the next step is to implement support for the ACP in 
the exacutiva (DC?) or device driver (FCP, OC?). This section 
follows the example UCP, so the special support will be added to 
the sample device driver. 

In aost cases, the ACP is being used with a new device 
driver. If this is the case, the r ecoaaendation is to Implement 
and test the device driver without AC? support. Once the driver 
is functional, it is a small step to add the ACP- 
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Tf the implementation uses a DC?/ the driver is •usisaiiy 
unaaare of the aCP/ not driver sjodif ications. are necessary . 
The AC? packet processing is done in DRQIQ« In the case of 
FCP's and DCP's/ the code to support the special processing for 
the ACP I/O packets is in the driver. In any case/ the 
functionality provided by the code is the same. The next tao 
subsections discuss the considerations on driver entry and ACP 
packet processing. 



3.4.1 Driver Entry 



For FCP's and UCP's/ the driver is called directly from the 
executive and the I/O packet is not queued/ because OC.QUE in 
the UC8 is set- The driver logic then determines if the packet 
is for the ACP or for itself- If the latter/ the packet is 
queued to the SCB and the driver calls $GTPKT to correctly 
sequence I/O service- The driver then processes the packet in 
the typical fashion- For ACP packets/ the special packet 
processing discussed in the next section is used- 

The folloHing code segment illustrates how the driver 
works- The example is taken from the driver for the example 
presented so far- 



* 

} DR¥INI IS CALLED MHESEVSR A I/O REQOEST IS ISSUED TO 
} THE SAMPLE DRIVER- THE PACKET IS NOT QUEUED AND THE 
; FOLLOaiHC REGISTERS ARE SET: 

} R1 = I/O PACKET ADDRESS 

; R4 = SCB ADDRESS 

; R5 = UCB ADDRESS 

DRVIMI; MGVB 
CMP 8 
8£Q 
CMPB 
BEQ 

} QUEUE PACKET 

4 
/ 

DRVPKT: MOV 
C ALL 
CALL 

acc 

RETURM 



I-FCN+ICRD/RO ;GET function CODS 
#IX.ACP/400/R0 ;IS THIS A ACP REQUEST? 



DRV A CP 


; IF 


SQ - YES/ GO 


PROCESS 


#IQ.CLN/400/R0 


>IS THIS A lO.CLN 


REQUEST? 


DRV ACP 


> IF 


SQ - YES/ GO 


PROCESS 


TO DEVICE AID GET 


NEXT 


PACKET. 




'J-SCB(R5)/R0 


4 r»TT' T 
/ ■ AJl/ JL 


DEVICE QUEUE 


LISTHEAD 


SQIHS? 


;QSSU 


S PACKET TO 0 


IS VICE 


SGTPKT 


/GST 


NEXT PACKET 




DRVSRV 


IF 


CC - SERVICE 


REQUEST 




F 


ACKET/ RETURN 
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3.4.2 Driver Packet Processiag. 



Qnca the driver decides the packet is for the ACP, it 
performs the special packet processing and queues the packet to 
the ACP. There are any number of special checks that could be 
performed and any number of methods to perforffl the check. The 
Digital approach used in DRQIO is to use polish-driven routines 
to perform each check. This allows a list of routines to be 
specified for each type of I/Q function. The same approach is 
used in the sample driver. 

More important than the technique used to process the I/O 
packet is the type of processing performed. The typical 
processing performed before queueing the packet to the ACP is 
listed below (the order of the list is basically the order the 
items would be applied; however, this is not hard and fast). 
The list of items below are typical of the processing applied by 
the executive for DCP style ACP's. The example driver code also 
demonstrates all of the below operations in its processing of 
the ACP functions. The rule which decides if the 
executive/driver or the ACP should perform the processing is 
whether the processing needs to be performed in the context of 
the task which issued the I/O request. If not, the ACP can 
perform the operation. Otherwise, the operation must be 
performed by the executive for DCP's and by the driver for FCP's 
and UCP's. Once a packet is queued to an ACP, an indeterminate 
amount of time and events may happen before the ACP dequeues and 
services the request. 

1. The function code is verified for leqal ACP function. 
The executive only checks the high byte when processing 
function codes, the driver needs to check any 
sub function fields. 

2. The OCB is checked to see if the ACP is mounted for the 
device • 

3. For functions which create I/O process, the OCB is 
checked to see if the ACP is marked for dismount. 

4. For functions which create I/O processes, the logical 
unit table is checked to see if a process is already 
active for the lun- 

5. For functions M-ftich must be mapped to an I/O process, 
the logical unit table is checked to see if a process 
is active for the lun. 

6. For functions which require a specific relationship to 
another, the window is checked to see if the function 
is legal for the current state of the I/O process. 
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7. If specific parasietars are xjot used or required^ the 
I/O paraiiie ters- are cdeckea to see if they are zero or 
non- zero. 

8- Any user task addresses are address checked. 

9. Any user task addresses are relocated so the ACP can 
sap the user task- 

10. In some cases#^ user buffers are copied to systes pool 
buffers. This allows the ACP to access information 
without mapping the user task. This Is especially 
applicable to attribute lists. 

11. The volume transaction count is incremented. 

12. If the ACP requires no further I/O request be issued 
from the lun^ the lun is locked- This is done by 
setting the low bit of the second lun word in the 
logical unit table. 

13- The packet is queued to the ACP and the ACP scheduled 
for execution- This is a simple operation which is 
done by calling the executive routine $EXRQP with RO 
set to the ACP TCB address and R1 set to the I/O packet 
address. 



3.5 ACP IMPLSMEhTATIOM 



Once the driver interface is finished, the ACP 
iaiplesentation can begin- Some of the implementation will be 
common to all ACP's. However, most will be unique to the 
application being addressed. 



3-5.1 ACP Packet Dequeuing 



One common function of all ACP's is the dequeuing of the 
I/Q packets queued to it from the axacutlve- The executive 
passes I/O packets to ACP's by linking them to the ACP's receive 
queue and scheduling the ACP for execut ion- The AC? retrieves 
tne packet by entering system state and dequeuing the first 
entry from its receive queue - 



The following code segment is taken from the example ACP 
and illustrates the basic root of an ACP. On task startup, the 
ACP initializes itself. Once done, it enters a loop where 
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packets are daqueuad and processed. If no Mock is founds ttie 
AC? stops itself, ihan- the- execnti^e queues' another packet^: the 
AGP Mill be rescheduled and can repeat the loop. 



?S£F. LASSL. 



MULAC?:: 

* 

; GO PERFORM THE IMIf lALIZATIOfl PROCESS. 

/ 



1000 $; 



CALL 


ACP I HI 


/INITIALIZE AC? 


SYSTEM 


STATE AND CHECK 


RECEIVE QUEUE. 


CLR 


R1 


/MARK NOTHING DEQUEUED 


CALL 


$SMSTK,2000$ 


//ENTER SYSTEM STATE 


MOV 


$TKTCB,R0 


//GET OUR TCB ADDRESS 


ADD 


#T-RCVL,R0 


//POINT TO RECEIVE QUEUE 


CALL 


$QRMVF 


//REMOVE QUEUE ENTRY 


BCS 


1100$ 


// IF CS - NO ENTRY, STOP 


MOV 

RETURN 


R1,4(SP) 


//RETURN PACKET ADDRESS 
//RETURN TO TASK STATS 



;mas entry found? 

; IF SQ - NO, CONTINUE LOOP 



; STOP task, mhen moke, return to task state. 

« 

/ 

1100$; CALLR $STPCT ;?ST0P current task (US) 

• 
f 

} IF NO ENTRY DEQUEUED, LOOP. 

2000$; MOV R1,R3 

BSQ 1000$ 

} 

} DISPATCH ON I/O FUNCTION AND CALL PROCESSING ROUTINE. 

« 

/ 

MOV I.UC8(R3),R5 ;GET UCB ADDRESS 

< function dispatch code> 

* 

/ 

} MHEN FINISHED, CHECK FOR DISMOUNT PENDING. 

} * 

4000$: BITB #0S.MDM,0,STS(R5) }IS A DISMOUNT PENDING? 

BSQ 1000$ ; IF EQ - NO, LOOP THROUGH QUEUES 

CALL ACPMDM >TRY TO COMPLETE DISMOUNT 

BR 1000$ ; NO LOCK - LOOP THROUGH QUEUE 

-END NOLACP 



3.5-2 ACP Packet Processing 



The real Mork of an ACP takes place after the packet is 
dequeued- Ho« ACP's process packets is strictly a function of 
the individual ACP. The sample ACP iliustratas some of the 
common types of processing that nay take place, such as reading 
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and wiriting-. buf f ars in the user task- However/ most of coda 
iapiefflented ' to ■ sarvica:: the- -packets- will be of- your own creation- 



3-5-3 ACP Packet Termination 



The final step an ACP takes In processing a packet is 
packet termination- This is done by calling the SIOFIll routine 
in the executive. This routine/ rather than the $IOOON/$IOALT 
routines/ should be used since the driver is not busy- 



3.6 TASK TSRMIKATIOM 



One important/ but often overlooked/ feature of ACP's is 
properly handling of user task termination- The RSX-llM 
executive sill not let a task exit until all outstanding I/O 
requests are terminated and all outstanding I/O processes are 
destroyed- The former is typically a function handled by the 
I/O driver- In the latter case/ the executive checks the second 
lun word for each entry in the logical unit table. If the value 
is non-zero/ an I/O process is assumed. The value would 
normally be the window block address- 

ahen a non-zero second lun word is encountered/ the 
executive constructs a lO.CLH packet and issues it as if the 
task had issued the QIO from the lun with the outstanding I/O 
process. The ACP is expected to abort the I/O process and zero 
the second lun word entry. 

The logic of the ACP must be able to handle an lO-CLN 
function no matter what the state of the I/O process- it is 
impossible to predict when a task will encounter an unexpected 
trap/ be aborted by the operator/ or exit without terminating 
all I/O processes. 



3-7 ACP SNASLING 



Two final steps- ramaln after tne ACP and driver are 
finished, A mechanism must be implemented to enable and disable 
the ACP for the devica. The camaqn name far these operations is 
mount and dismount. Thera are a variety of methoas that can be 
used- These are discussed in detail in chapter 6. 

ACP mounting is really quite simple- The complexity of 
Oigital's MOO task comas from the multiple functions it provides 
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and tile details of actually performing a Flies-11 or ANSI 
magtape mount* The assential steps , that must be accompl.ished 
when an ACP is mounted are listed below- The first list 
contains steps typically performed by a separate enabling task. 
The sample task EM& demonstratas each. of the staps- 

1- If wanted, get any '• mount- time** options from the mount 
command line- It may be necessary to allow operator 
specified options to provide greater ACP flexibility. 

2- Check if the device is mountable (DV- HMT=1)- 



Check if 
(US.MMT=1). 


the 


device 


is 


not 


currently 


mounted 


Check if 
(US.MDM=0). 


the 


device 


is 


not 


marked for 


dismount 



5- Allocate the yCB from system pool and store its address 
in U-VCa of the 0C3- 

6. Search the task directory for the ACP task and get Its 
TCB address- 

7- Check the found task is an ACP (T3-ACP=1)- 

3- Store the ACP's TCB address in U-ACP of the HCB. 

9- If necessary, add an entry to the mounted volume list- 
This will typically not be required for user-written 
ACP's- 

10- Schedule the ACP task for execution. The ACP will then 
typically start with Its initialization code. This 
step is traditionally combined with a 10. MOO request 
being queued to the ACP. This request contains the 
'*mount-time" parameters for the ACP. The 10. MOO 
request is not necessary if no information needs to be 
communicated to the ACP. 

11- If the 10. MOO I/O request was Issued, wait for 
success/failure- ^ If failure, output an error message - 
Otherwise, just exit. 



The r-aaaining. steps in the mounting process, are typically 
performed by the ACP. These steps are as follows! 

1. If an 10-1400 request was queued, dequeue it from the 
receive gueua and process tne parameters. 

2- Count the device mounted. This is usually an internal 
ACP counter- 
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3. Perform any device I/O necessary for the ACP to become 
active. 

4. Mark the device mounted CUS.MST=0)» 

5. Enter the ICP main loop. 



The steps above are followed by the sample ACP and EUA 
task. This code can be used as a template for your ACP 
implementation# or one of the alternate approaches discussed in 
chapter 6 can be used. In any case# in order for an ACP to be 
successfully mounted# the following must have happened: 

1. The yCB has been allocated and its address stored in 
U.VCB. 

2. The ACP's TCB address must have been stored in U.ACP. 

3. The ACP must have been marked as mounted (U3.MHT=0). 

4. The ACP must be active and ready to receive ACP 
functions. 



3.8 ACP DISABLIliG 



The last step in the checklist is to implement the ACP 
disabling (dismount) mechanism. If the system will not function 
without the ACP, no dismount mechanism other than rebooting may 
be needed. However# usually a dismounting method will be used. 
The following steps are usually accomplished by a dismount task. 
The sample OIS task demonstrates these steps. 

1. Check if the device is mountable (DV.MNT=1)* 

2. Check if the device is mounted {03.MST=0). 

3- Check if the device is already marked for dismount 
{US-MDM=1). 

4. Mark the device for dismount (OS-MDM=i). 

5. Construct and queue an lO.OMO request to the ACP. 

6. Wait for coapiation of the lO.OMQ and exit. 



When an ACP receives a dismount request# it typically 
performs the following steps. 
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1« Macks a dismount is pendinq for tha device. This can 
already be considered done as the* OS.MDM' bit is- sat in 
the UCB. 

2. Return the lO.DMQ request. 



After a dismount becomes pending, the ACP then waits for 
ail activity to the unit to cease. This means no I/O requests 
are outstanding and ail I/O processes have terminated- Mhen 
this occurs, the following steps are taken- 

1. Hark the device dismounted <0S-MNT=1). 

2- Mark the dismount complete (US.MDM=0). 

3- Perform any device I/O necessary to deaccess the ACP 
from the device. 

4- Return the ¥C3 to the pool and zero U.¥C8. 

5. Zero the U-ACP word in the UC8- 

6. When all mounted units are dismounted, exit the ACP. 



3-9 CHECKLIST SUMMARY 



This chapter has described all the steps necessary to 
implement an ACP. The checklist presented here was followed to 
implement the sample ACP, its driver, and the ENA and DIS tasks. 
These routines can be used as a basis for a user-written ACP, 
leaving only the Job of solving the actual problem. 

It is usually easiest to implement a OCP- This involves no 
modifications to the executive and is a straightforward approach 
once the checklist is followed- For the more advanced 
programmer, the DCP and FCP approaches may offer advantanges- 
However, you are at the mercy of Digital with regard to their 
future executive implementations. 

The ramaining chapters discuss the material prasented here 
in more detail. in particular, they present the philosophy 
behind the actual operations. 




CHAPTER 4 



ACP/TASK IMTERFACS 



A user task interfaces to an ACP using the QIO directive. 
The I/O requests can be issued directly froa the task or from 
one of the logical I/O service libraries: FCS or RMS. This 
chapter discusses the ACP/task interface froa the first tuo 
perspectives. The RMS sources are unavailable to the author. 
However, the approach used for adding an new ACP to FCS is 
expected to apply to RMS. 



4.1 QIQ INTERFACE 



The fflost coaaon way to interface to a user-written ACP is 
the QIO directive. In an RSX-llM systeo, all I/O is requested 
using this directive, including I/O from ACP's. Adding support 
for I/Q service froa a user-written ACP is the same as adding 
new QIO directives for a user-written driver. The only 
decisions necessary are what function codes the ACP will service 
and the I/O parameters that will be used for each function. 



The choice of I/O function codes is slaple. If existing 
Digital function codes apply to the new ACP, they should be 
used. When using existing codes, the I/O parameters should also 
be the same as the current Digital format. Then, no errors will 
occur when I/O is directed to different devices. 

However, the more typical case is that the new AC? will be 
iiaplenenting new functionality. In this case, the less 
frequently used I/O function codes snouid be considered. These 
are the codes froia 25-3K10). The subfunction field can be used 
to actually distinguish between separate ACP functions. 

3acausa ACP '3 typically use special procassing for the 1/3 
paraiaeters, there is a great deal of freedom in their layout. 
The parameters can be as complex as needed to pass and receive 
information from the ACP. 

One common technique used by ACF's to allow passing of many 
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■paraiaetars are attribJuta lists, ,4n attribute list is a buffer 
^bicn- con tains, attributa descriptors, Saca descriptor describes 
a separate parameter to the AC?. A typical attribute descriptor 
consist of a cods to identify the attribute, tne address of the 
actual attribute, and size of tbs attribute, ’ishen the I/O 
request is processed, the special processing code maps the 
attribute list and individually address checks and relocates the 
attribute addresses. 

This technique is used by FlllCP to alios* reading and 
writing of the various fields in the file header. When the 
attribute list is processed, a buffer is allocated from the 
systeai pool and the attribute code and size are copied from the 
user task. The attribute buffer is relocated and the relocation 
bias and displacement are stored in the system buffer. When the 
I/O packet is received by FllACP, it can use the information in 
the system buffer to read and write the attribute buffers in the 
user task. Appendix D contains a detailed description of the 
Files-11 attribute list processing. Also see the DRQIO module 
for an example of how the executive processes attribute lists. 



4.2 FCS INTERFACE 



In some special cases. Interfacing an user-written ACP to 
FCS can result in significant advantages. FCS is the component 
of RSX-llM that provides device Independence and record I/O. 
FCS examines the device characteristics of the assigned device 
and issues I/O appropriate for the type of device. For example, 
if a terminal is the assigned device, a PUT$ request will result 
in a IQ.WV8 being issued to the terminal. However, if the 
device is a disk, FCS will block the record to the virtual disk 
block. 



By adding support for new ACP's to FCS, users can perform 
1/0 from PCS to the devices supported by the ACP. In addition, 
the languages and utility programs which use FCS will then 
support the new device. For example, Fortran I/O uses FCS. If 
FCS supports the new ACP, standard Fortran I/O statements could 
be a powerful method of performing I/O. The users of the ACP do 
not have to learn any new syntax to use the ACP and its devices. 

Only a fraction of user-written ACP's are candidates for 
intarfacing to ?C3, The typical application will invoivs an 
iapiamsntation of an alternate file system. For example, if an 
ACP was written -to- support RT-ii disks, interfacing. the AC? to 
FCS would allow the standard SSX-llM utilities to directly read 
and write RT-11 files. Another possibility is an ACP which 
supports remote I/O. For example, an ACP could implemented 
Digital's Data Access Protocol (DAP). If such an ACP was 
interfaced to FCS, RSX-llM programs could transparently access 
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remote file and devices- 

Thera are tuo methods for intarfaciag a osar-writtan AC? to 
?G3- if the ACP aces the Files- 11 the new ACP merely 
needs to eauiate the services supplied by FllACP. Mith this 
approach, little or no modifications Mould be needed to FCS- 
Houever, the ACP Mill probably have to go to great lengths to 
translate the device protocol into Files-11 compatible format. 

The other approach involves modifying FCS to perform unique 
operations for the new ACP. Here, the goal is to provide 
complete compatibility at the user Interface into FCS. In other 
words, the functionality documented in the RSX/IAS I/O 
Operations Reference Manual is provided by the coabination of 
the modified FCS and the new ACP. As long as a program does not 
depend on Fiies-11 specifics, it should function correctly when 
used with the new ACP. 



There are no. hard and fast rules which apply to adding 
support for a new ACP to FCS. The overall approach is to 
examine hoa FCS operates for current ACP's and modifying the 
appropriate points to add logic for the new ACP. The next four 
subsections comment on some of the basic points. In addition. 
Appendix C provides detailed descriptions of each FCS module and 
the various data structures. 

Some general rules are to apply conditional assembly 
statements to all new coda and to maintain object-level 
compatibility. By conditionalizing the new code, differant 
versions of the FCS library can be maintained. For user tasks 
which do not need to support the nea ACP, the Olgital standard 
version of FCS can be used. Only tasks requiring the new device 
support need to be linked to the special version. By 
maintaining objact-levei compatibility, a task needs only to be 
relinked to receive the benefits of the new support. 
Object-level compatibility requires that the code generated by 
the FCS macros is not changed by the modifications. In 
particularly, the space generated for the File Descriptor Block 
and Filename Blocks should stay the same. However, fields 
within these data structures can be redefined by the modified 
FCS for support of the new device. 



4-2-1. File Specif icat,ion 



The FCS modules can be broken into four categories- The 
first are aioduiss wnich are concerned with parsing the file 
specification Into the device, directory, and filename 
components and assigning the user lun to the specified device - 
The major modules in this category are the four parsing modules: 
PARSE (parsing control), PARSOV (parse device name), PARSDI 
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(parse dixactory)/ a:nd PARSFfi (parse filanaae). In addition^ 
t-ha aSSLdH: aodule assigns- tde user Inn to the specified device 
and reads tiie device characteristics* The auxiliary directory 
modules (.DIDFMD/ OIFSD^.. GElUl, GETDIO, GSTDIR, P180I, and 
PA80ID) process filas-il directory files. Finally, the RSX-llM 
coaiaand scanning routines (CSIl, C3I2) are used to scan entire 
coffiiaand lines 

¥hen adding support for a new AGP, the major concern for 
these modules is to add support for any new fora of file 
specifications and to set up the PCS device characteristics. 
For example. If adding network; file support, it would be 
necessary to add a nodenaae field to the device specification. 
If adding RT-11 support, the routines would have to be modified 
to ignore or declare an error if a directory was specified. 

The key is the fact that the first step performed by FCS 
for all operations is to assign the lun to the specified device 
and establish the device characteristics. The ASSLON module 
performs the assignment and gets the device characteristics. It 
stores the low byte of the devices O.Cil field in F.RCTL and the 
device buffer size in F.yssz and F.8BS2. The important field Is 
the device characteristics byte. This byte contains the bit 
masks which are examined by FCS to determine the appropriate 
operation to take for a device. For example. If the 
record-oriented bit (FD.REC) is set, FCS assumes the device is a 
terminal-like device and performs no record blocking. If the 
bit is clear, a block-oriented device is assumed (disk) and 
records are block within virtual blocks. Therefore, the first 
step in adding support for a new AC? is to modify PARSD¥ and 
A3SL0M to correctly assign the new device and to establish 
device characteristics which will allow other FCS modules to 
uniquely identify the new ACP. Then, whenever special 
processing is needed to support the new ACP, the F.RCTL field 
can be tested and the a branch made to the appropriate code. 
For example, special directory and filename parsing logic can be 
invoked if the device is established as a RT-11 disk volume. 
The easiest method to identify a new type of device is to use 
one of the undefined bits in the F.RCTL field (bits 6 and 7) and 
set the remaining bits as appropriate for the new device. 



4.2.2 File Access 



The next category of FCS modules are the various OPES 
routines. FCS supports three methods of opening files: normal, 

fiianaffle block, and xiie-ID. The first fora calls the parsing 
routines to setup the filename block and then opens the 
specified device/file. The filename block version assumes the 
parsing routines have already been called. The final fora uses 
information from a previous file access to directly open the 
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fila.. So parsing logic is ini^oked. 

Adding a new AC? aierely involves dispatching at the 
appropriate point in the QPSR logic to perfora any I/Q required 
by the' AC? to establish an I/O process. The .new logic is 
responsible for returning the appropriate information to the 
FD8/ particularly the file-attribute section (F.HTYP, F.RATT, 
f.RSiZ/- F.HIBK^ F.EFBK, and F.FFBY). These fields are used by 
FCS to deterffline how records should be processed^ when new 
blocks need to be allocated to the file/ and where the logical 
EOF is positioned. For Files-il/ these fields are stored in the 
fila header. FCS retrieves them when an existing file is opened 
and stores the current FDB values when a file is created. 

Unless the new type of device supports some unique file 
identifier/ the open by file-ID mechanlsia will either have to be 
emulated by the AC? or made illegal. The most common use of 
file-ID "s is by programs which open a file briefly/ close it, 
and reopen it at a later point in time. The flle-ID from the 
first open is saved and reused on the next access. For example/ 
the MACRO assembler uses this technique. One method for an ACP 
to emulate file— ID's would be to save file names in a 
ieast-recently used buffer or file and assign a number to map 
the entry. If an open by file-ID is attempted/ the flle-ID is 
used to address the table and retrieve the original file 
specification. When a new filename is entered/ the oldest 
previous entry is destroyed. In this fashion/ the most common 
use of file-IO's by RSX-ilM utilities can be supported. 



4.2.3 Input/Output 



FCS supports two forms of input/output. The first is 
record I/O which uses the GET$/POT$ calls. The other form is 
virtual block I/O and is implemented by the REAO$/WRITE$ 
routines. The general approach for adding support for a new ACP 
is the same as for the OPES routines: add logic at the 

appropriate points to test for the new ACP and branch to special 
I/O logic. 

It is important to remember that FCS is the element of 
RSX-llM that defines what is a record/ not Files-11. When 
performing record output to a disk/ FCS packs the records into 

disk blocks and issues write virtual blocks to FllACP. 

Similarly/ when inputting records from a disk/ PCS inputs 

virtual blocks and unpacks the records using the record 

information it originally provided wnan the record was written- 
Most importantly/ user programs do not care that block I/O is 
being performed for their record I/O. They are only Interested 
in the record itself. 
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Therafoc3/ if the concapt of block I/Q does not apply to 
the ne«- ACP, theca is. ao need for -any new logic, to be .added to 
FCS to block tfsa user racords. Instead, each GET$/?UT$ call can 
result in an I/O request to the nea AC?. fCS biocK I/O can be 
treated as raecaly fixed-ianqth record I/O. . An exasapla souid be 
an iCP whicri iaplements the DA? protocol. The protocol is only 
concerned with records, so each GET$/POT$ call would generate an 
input/output record request to the AGP. This greatly siinpllfies 
the modifications necessary to FCS because all the code 
concerned with record blocking can be bypassed. 



4.2.4 File Control 



The final category of FCS routines are used for file 
control operations; delete, renaae, truncate, extend, etc. The 
modules in this category are straightforward and can be modified 
for support of a new ACP with little difficulty. 

If a particular operation is not appropriate for the new 
device. It can either be ignored or an error returned. For 
example, FCS has a user call to enter a filename into a 
directory. It would typically be appropriate to just return 
success if this operation does not make any sense to the new 
ACP. 




CHAPTER 5 



ACP/SJ(ECHTi?E IMTESFACE 



The ACP/ executive interface is almost totally contained in 
two executive modules: QRQIO and lOSUB. These modules are 
concerned with processing user I/O requests and providing the 
common I/O services used by drivers and ACP's. This chapter 
discusses the basic principles of ACP I/O processing and walks 
through the code used for each style of ACP. 



5.1 EXECUTIVE PROCESSIMG REQUIREMENTS 



The module DRQIO contains all the code to transform a user 
I/O request into its internal representation and route the 
resulting packet to the correct device and/or DCP. For FCP's 
and UCP's^ DRQIO is used to perform the common operations and 
device drivers are used for any unique processing required by 
the ACP. For this section^ where any particular piece of code 
is placed is ignored. The emphasis is on the operations that 
must be performed before an I/O packet can be queued. 

Up to a certain pointy user I/O requests must be processed 
in the context of the user task. The following list documents 
operations which fall into this class. 

1. Any address in the user task space must be validated. 
Specifically, the address of the QIO directive 
parameter block, I/O status block, AST address must be 
checked. In addition, any addresses in the I/O 

parameters must also be address checked- 

2. Any address in the user tasic space- to be used by the 
device driver or ACP must be relocated to a address 
bias and disp iacameat. In other words, the 16-bit user 
virtual address must be converted to a physical memory 
address in order for ACP's to access or store 
information. 
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The ai30ve list applies eqiialiy to I/O for drivers and 

ACP'3, When the executive • deteraiines a' I/O packet is to he 

routed to an ACP, there are soae other tests Hiiich aust be 
applied before the paoxat can be queued to the ACP, ACP's are 
running as tasks and are aif acted by the scheduling algorlthas* 
Therefore, an indatarminate amount of time may aiapsa before an 
I/O packet queued to an AGP is actually processed by the AGP. 
This requires the state of the AGP and any I/O process be 
checked before the packet is queued and that no changes in the 
state can be ailoued until the packet is dequeued- The 
foiloaing operations fall into this class: 

1. The device must be checked to see if the AGP is 

mounted. This is done by checking the US.HOO bit in 

the U-STS field- The bit will be zero if the AGP is 
no unted - 

This rule imp lies the state of the US-MOU aill not 
change once the I/O request is queued to the AGP until 
it is dequeued. This is the reason for the transaction 
count (see below). An AGP should not be narked as 
dismounted until the transaction count for the device 
is zero. 

2. The device must be checked to see if the AGP is marked 
for dismount- This is done by checking the OS.MDM bit 
in the U.STS field. The bit will be set if a dismount 
has been requested. 

Mhen an AGP is In the nark ed-f or -dismount state, no new 
I/O processes should be allowed- Therefore, this test 
is only performed for I/O requests which will create an 
new I/O process. The test will not be applied to any 
functions which operate on an existing I/O process- 

3. For functions which create I/O processes, a check must 
be made to see if an I/O process is already created for 
the user lun- This is done by checking the second word 
in the LUT table entry for the presence of a window 
block address. If the word is zero, no I/O process is 
In effect and the request can be allowed. 

This rule implies that an I/O process will not be 
created for the user lun once tne I/Q request is queued 
to the 4CP and until it Is daquaued by . the ACF. Thi.3 
is the reason the the luo lock bit i,a the- LOT table.. 
When the lock bit is set for a user lun, the user task 
cannot issue any further I/O request from the logical 
unit. Tharafora, t.ha I/O p.ackat processing will set 
the lock bit when a I/O packet which creates a process 
is queued to the AGP and clear the bit once the process 
is created. Similarly, functions which destroy I/O 
processes will also set the lock bit to insure proper 
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synchronization betaeen tha AC? and the osar task* 

4« For functions which must be mapped to an I/O process^ a 
check must be parforaed to see if the I/Q process 
exists* This is done by checking the second word of 
the LUT table entry for the presence of a aindoH block. 
If the word is non-zero, an I/O process is in effect 
and the request can be al lowed - 

5. Finally, any specific reiationships required by the ACP 
between I/O requests are checked* For exampla, an ACP 
aay not allow a particular operation until some other 
criteria have been established- This is done by 
checking information in the window block. 

Also, the window block may contain enough Information 
for the I/O requests to be mapped at this point and 
queued directly to the device driver. This is what 
occurs for I/O to disk files. If the disk window block 
contains the mapping information for the read/write 
virtual request, the remapping is performed directly 
and the packet is sent directly to the disk driver. 
Otherwise, the read/writa virtual request is sent to 
the ACP which updates the window information and routes 
the packet to the driver. 



The purpose of the transaction count is to Insure no change 
in the state of the ACP can occur between the time the state is 
checked and the I/O packet is actually received by the ACP. 
Therefore, an AC? can only be dismounted when the transaction 
count is zeroed. The transaction count is Incremented whenever 
a packet is queued to the ACP and decremented whan the ACP 
completes the packet. The transaction count is also used to 
indicate the presence of I/O processes. 

Similarly, the lun lock bit Is used to insure the I/O 
process state is not changed between the time the state is 
checked and the packet is dequeued by the ACP. Whan this bit is 
set, the executive guarantees no I/O request can be issued from 
the lun. Therefore, any I/O request which will change the state 
of the I/O process should lock the lun before the request is 
queued to the ACP. The bit does not need to be set if the I/O 
request will not affect the process state- 



5.2 DC? lilTSRFACS 



All of the operations described by the previous section can 
be observed by reading how I/O requests are processed for DCP's. 
The overall process is described by the RSX-llM Guide to Writing 
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an I/O Orivar isanuai* In addition^ the RSX-lliM Systea Logic 
Manual contains a floa-chart of the- axecutlva processing-" in 
Chapter b. 

The above descriptions are orientad touards processing of 
functions anich aill eveatuaily be routed to device drivers. 
The next two sections outline the processing that occurs for a 
I/O function which will be routed to a DCP. The following notes 
assuae the I/O request is to be routed to FllACP and that the 
following features have been selected/not selected/optional: 



A$$CHK Address checlcing 
A$$CPS ACP support 
D$$1AG On-line diagnostics 
L$$DRV Loadable drivers 
M$$MGE Meraory aianagement 
M$$MOP Multi-user protection 



selected 

selected 

not selected 

optional 

selected 

optional 



5.2.1 $DRQIQ Processing 



All QIQ directive processing starts at the label $DRQIO in 
the DRQIO fflodule. The first operations apply to all I/O 
functions. The initial code checks that a GIO is legal at for 
the current task and device state. Then the parameters to the 
910 are verified. The following checks are made. If all checks 
prove false^ processing continues with at label 24$. 

1. The lun is mapped to the device and any redirect 
pointers are followed. If the lun is illegal 
(CQ.I0LM3 > Cfl.MLUSl), a directive error of -96. is 
returned. 

2. If the lun is unassigned (Cfirst lun word! = 0)^ a 
directive error of -5. is returned. 

3. If the lun is interlocked for use (bit 0 Csecond lun 
word! = 1), the task PC is backed up to reissue the QIQ 
and the task is placed in MAIT FOR SIGNIFICANT EVENT 
state. 



?iOT£ 

This is the feature use by ACP functions to 
synchronize access to the I/O pcocassas. 



4. If the driver is not resident (CD.DSP3 = 0)#- a 
directive error of -6. is returned. 
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0 « 


If an event flag was:^ specif ied. 


cl 


ear it. A 


directive 




error of- -97. is returned 

illegal. 


if 


the event 


f lag ■ i 3 


6 . 


If an I/O status block address 
address and clear both uoras. 


was 


specif iaa. 


check the 


7. 


Allocate an I/O PACKET, If this 

error of -1. is returned. 


fails a 


directive 



MOTE 

This is the last possible directive error. 
Both the event flag and I/O status are 
cleared before this error can be detected. 



8. Increment the outstanding I/C count 

(CT.IOCl <- CT.IOCl+l). 

9. If the function «as QIOH and an event flag Has 
specified, place the task in WAIT FOR EVEHT FLAG state 
for the specified event flag. 



If no directive errors occured, the coinfflon fields in the 
I/O packet are filled in. The code that performs this step 
starts at label 24$. The next step is dispatch based on the 
type of I/O function. The following steps are performed: 

1. If the I/O function code was kill I/G (CQ.IOFN+13 = 0), 



control is 


passed 


to 


the kill 


I/O code. 


This code 


calls $IDKIL 
function. 


and returns 


success 


for the 


kill 


I/O 


, If multiuser 


support 


uas 


selected 


(M$$M0P), 


the 


I/O 



request access to the device is checked. Access is 
denied and an I/O status code of IS.PRI is returned if 
the all of the following are true. 

1. The device is owned (CU.OMMJ # 0). 

2. Public access is not aiioweo. (bit US-POB, 

C0.ST23 — 0)« 

3. The currant ownsr is not the task that issued the 
I/O request (CO.O’rfMO £T.aC3 of current task!). 

4. The current task is not orivileged (bit T3.PHV, 
CT.ST30 =0). 
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The 


I/O function 


code 


i s 


checked 


to m- 


aka 3UT 


e it does 




not 


■excaad the 


:i?axi 


mum 


/ 'C' d hj 

\ ^ Ju m 


If 


It is a 


oes, an I/U 




status code of i: 


a.iFC 


is 


returnef 


U 






4m 


The 


I/Q function 


coda 


is 


changed 


into 


a b i t 


mask. 



5. Tha I/O function code is checkad against the legal 
function table in the DCB, If It is not legal, an I/O 
status code of IS.IFC is returnad. 



6. The device is checked to sea if it is offline (bit 
OS.OFL, C0.3T23 =1). If it is, an l/Q status code of 
lE.QFL is returned* 

7* The I/O function code is checked against the control 
function table in the DCS* If it is, control is passed 
to control function service. This service copies the 
six I/O paraaetars to the I/O packet and continues at 
$ORQRO. 



NOTE 

This is the point a UCP departs from the 
normal DCP packet processing. See section 
5.3 for a discussion of ho« the remainder of 
the packet is processed. 



8. The I/O function code is checked against the no-op 
function table in the DCB. If it is, an I/O status 
code of IS. sue is returnad. 

9. The device is checked to see if it is not mountable 
(CU.CM13 > 0). If it is not, control is passed to 80$ 
and the following checks are made. 

1. The I/O function code is checked against the ACP 
function table in the DCB. If it is not an ACP 
function, control is passed to the transfer 
function service code. 

2. If function is an AG? function, the function code 
Is changed to TO- sLB unless the' I/O function code 
was IQ.hfB ahica is canvartad. to I0.RL3. Control 
is then passed to the transfer function service 
coda. 
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riOTE 

If you get here, tfae I/O function code 
iHust be either I0«R¥B or IQ«^¥B. All 
others Mill be handled incorrectly. 



At this point/ the function is knoan that the function is 
for a device which could have an ACP servicing it. The first 
check performed is to see if an ACP is mounted or is mounted as 
foreign. If the device is not mounted or mounted as foreign 
(bits US.MHTlOS.FOa C0.STS3 = 0), control is passed to 60$. If 
no AC? is mounted (bit US.MMT/ C0.STS3 = I), the following tao 
steps are performed. 

1. If the function is an ACP function# an I/O status 
return of lE.PRI is made. 

2. Otheraise the control is passed to the transfer 
function service coda. 



If instead# a foreign ACP is mounted# control is passed to 
label 65$ and the foreign ACP processing is used. 



NOTE 



This is the point a FCP-style ACP departs from the 
normal DCP packet processing. See section 5.4 for 
further details. 



If the device is mounted by a knoan ACP# a check is 
performed to see if the function is an ACP function. If it is 
not# a branch is made to label 75$ and the following checks 
made: 

1. If the I/O function Is load overlay (lO.LQY)# 

processing continues as if the function is a transfer 
request. 

2. If the issuing task is privileged (bit T3.PRV# 

ET.ST33 = 1)# the function is ailowed and treated as a 
transfer request. 

3. Otherwise# an I/O status error of lE.PRI is returned. 
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At this point/ ORQIO has finally cacognized the I/O 
111001x013 as an AC? function to a mounted : deylca.. The spacial 
processing code used for DCP's Is than Invoicad. This is 

performed by using the polish tables listed in the front of 
ORGIO* These tables are used to correctly dispatch AC? 
functions to the appropriate setup routines. The tables have 
t«o parts. Table FCDSP contains the starting address of the 
appropriate polish table for each function. This is folloued by 
the polish tables. The registers and stacx are setup as shoan 
beloM when the dispatch into the polish code begins. 



RO 


3 = 


Address 


of 


UC8. 




R1 


— 


Address 


of 


second 


lun word. 


R2 




Index into 


polish 


function dispatch table 


R3 




Address 


of 


Q.IOPL 


in QIO DPS. 


R4 




Address 


of 


I.PRM 


in I/O PACKET- 


R5 




Address 


of 


next polish dispatch vector. 


(3P) 




Address 


of 


second 


lun word. 


(3P)+2 


=: 


Address 


of 


0C8. 




(SP)+4 


:= 


I/O function code. 





The processing performed by the individual polish routines 
is listed below. To see which routines are used by a particular 
OCP function, see the tables In DRGIO. The routines are listed 
In alphabetical order. 

BDPKT - This routine completes the I/O packet for FllACP 
and MTAACP. It expects the following I/O 
parameters in the QIO request; 



Q.IOPM+0 

Q.IGPM+2 

Q.IOPM+4 

Q.IQPM+6 

Q.IOPM+10 

Q.iaPM-l-12 



Address of fiie-ID 
Address of attribute list 
Extend control word 1 
Extend control word 2 
Access control word 
Address of filename block 



The file ID block and filename block are relocated 
if present. The attribute descriptor block is 
processed by allocating a buffer from the system 
pool and copying the attributes from the user task 
to the system buffer. The attribute addresses are 
relocated. If any address do not check out, an I/O 
status code of IS.3PC is returned. Otherwise it 
dispatches to the next entry. 

'^'hen 3DPKT is finished/ the parameters in the I/O 
packet are formattad as follows: 

I.PSM+00 = File-ID relocation bias 
I.PRM+02 = File-ID raiocation displacement 
I.PRM+04 = Address of system attribute buffer 
I.PRM+06 = Extend control word 1 




ACF/EXSCOTI¥£ IHTERFACE 



PAGE 5-9 



I,PRM-+iO = Extend control aoro 2 
I*.?RM+12 =' Accass control aorci 
I.PRM-+14 = fllanaffle block bias 
I..PHH+16 = Fllenaaie block displacaiaa.nt 

CKALU - Tills routine checks if a file is already accessed 
on the lun (Csecond lun aordl # 0) and returns an 
I/O status code of lE.ALli if so« Otherwise it 
dispatches to the next entry. 

CKCON - This routine copies the QIO parameters into the I/O 
packet. The routine requires the first two 
parameters to be a buffer address and size and 
relocates the buffer before storing- If the buffer 
is not specified or is illegal^ an I/O status code 
of IE-8AD is returned. Otherwise It dispatches to 
the next entry. This routine is used for DECHET 
processlng- 

CKDIS - This routine copies the QIQ parameters into the I/O 
packet and dispatches to the next entry. It Is 
used for processing the DECNET disconnect request. 

CKDMO - This routine checks if the volume is marked for 
dismount (bit OS. MOM, CU.STS3 = 1) and returns an 
I/O status code of lE.PRI if so- Otherwise it 
dispatches to the next entry - 

CKMOU - This routine checks the mounted volume list to see 
if the volume can be access by the user. If the 
volume is public or the user is entered in the 
mounted volume list, the routine dispatches to the 
next entry. Otherwise an I/O status code of lE-PHI 
is returned. 

CKMLS - This routine checks if a files is accessed on the 
lun (Csecond lun word! # 0) and returns an I/O 
status code of lE.HLh if not. Otherwise it 

dispatches to the next entry. 

CKHAC - This routine checks if the user has read privileges 
for the I/O process. If processing for FllACP, the 
window is then addressau to see if the read request 
can be directly mapped and queued to the driver- 

CXMAC - This routine performs tne same processing for writ a 
requests that CXRAC performs for reads. 

CaXIT - This routine cleans the stack, increments the 
volume transaction count (C?-TRCTD <- CV.TRCTl+1), 
and exits queue I/O PACKET coda (see section 7). 

■Ahen all polish processing is finished, control Is passed 
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to label FCXIT. The polish code flags 
queued directly to the AC? or needs to 
driver for proper synchroaization. 
contains a complete description of the 
perforaed by the axecutive. 



whether the packet can be 
be queued- to the device 
The listing of DRQIQ 
queueing and interlocking 



5-2.2 $:0SQRQ Processing 



The second entry in the ORQIO module is $DRQRQ- This is 
the code that queues I/O packets to drivers and calls the driver 
initiator- The following steps are performed- 

1- Get the SCB address (C0-SC83)- 

2. If the packet is not to be queued (bit flC.QBE^ 
CO.CTLO =1)^ goto step 4. 

3- Queue the I/O packet to the SCB I/O queue- 

4- If the driver is loadable/ aap KISAR5 into the driver- 

5- Call the driver at the initiator entry point- 

6. If the driver is loadable/ restore KISAR5 to its 
original contents. 

7. Exit from the DRQIQ code- 



NOTE 

The entry $DRQRQ can be used to queue an I/O packet 
that has been constructed by other means- R1 should 
be the packet address and R5 the UC3 address- 



5-2-3 $GTPFT Processing 



The executive normal ly queues I/O packets to OCR's from 
DRQIO. Hoaever/ if the packet needs synchronization with the 
aevice driver/ it is queued to tne device instead- The routine 
SGTPKT is used by device drivers to gat their next packet- Mhen 
$GT?KT recognizes the I/Q function as an ACP function/ it queues 
the packet to the AC? and loops to attempt to dequeue another 
packet for the driver- The tests for this step occur at label 




ACP/ EXECaTI^E IIJTERFACE 



PAGE 5-11 



80$» BasicailYy SGTPKT assumes if the device is mountable 
(1IU-.CM11 < 0) and an OOP— style iCPy ail I/O functions, fros 1 to 
31 {10) should be queued to the ACP, 

If the AC.P is mar iced as foreign^ $GT?KT will check the DCS 
function dispatch aasks to see if the function is for the ACP. 
If the DCS mask bit is set, the packet will be queued to the 
ACP, otherwise, it is returned to the driver. 



5.3 UC? liSTERFACE 



ClCP-style ACP's are used to avoid aodifylng the executive, 
particularly DRQIO, for support for the new ACP. Section 5.2.1 
notes the point in the I/O processing where the OCP approach 
deviates from the traditional ACP packet processing logic. 

The deviation occurs because the I/O function is marked for 
control processing. Control functions are processed beginning 
at the label FCCTL. First, the device is checked to see if it 
is a mountable magtape device and the I/O request is rejected if 
the task is not privileged. To avoid this processing, the 
US -LAB bit in the UCB status byte (O.STS) should be zero. 

The next step is to copy the six QIO parameters to the I/O 
packet. This done by a call to FCXPl at label FCXOP. No checks 
are made on the paraaeters. Once the parameters are copied, the 
packet is passed to $DRQRQ for queueing to the device. Here, 
the packet is passed directly to the driver initiator because 
the UC.aUE bit in the 0C8 control byte (U.CTL) is set. The 
driver than performs any processing necessary and queues the 
request on to the ACP. 

Note that the UCP interface does not require any 
modifications to the executive. In addition, the interface uses 
standard features of the I/O mechanism. Therefore, OCP-style 
ACP's can be interfaced easily to fiSX-llM and future operating 
system releases will not affect the user-written code. 



5.4 FCP IHTERFACS 



The interface for FCP's is very similar to the OCP 
processing. The FC? logic is invoked if the device Is marked 
mounted and foreign and the function masks indicate an ACP 
request. Section 5.2.1 notes the point in the I/O processing 
where the FCP approach deviates from the DCP logic. 

The FCP logic first checks if an ACP has been specified by 
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caacxiag. that U»AC? in the UC3 is oonzsro* If the location is 
raro/. a p ci vilege- 'Violation ^ is declared (I£-.?-Ri)» lext/ if a 
7Ca address is stored in iJ-'/CB, the 7C3 transaction count is 
incraasented. 

The next step is to copy the six QIQ para®eters to the I/Q 
packet. This dona by a call to FCXPl at label FCXGP. Note/ at 
this point/ the processing is identical to the UC? interface. 
HoMaver/ if the OC.QOE bit is not sat/ the packet is queued 
directly to the AGP. Qtheruise/ the packet is passed to $DRQRQ 
for queueing to the device and the packet is passed directly to 
the driver initiator because the UC.QOE bit In the UCB control 
byte (U.CTL) is set. The driver than performs any processing 
necessary and queues the request on to the AGP. 

Mhile the FCP approach does not require any modifications 
to the executive/ it does depend on continued support for 
foreign AGP processing. For this reason/ the UCP approach is 
favored If all other considerations are equal. The main 
advantage of FCP's is the support provided by iMQO and DMQ. 



5.5 AC? INTERFACE 



No matter how the I/O packet is processed/ the actual 
queueing to the AC? is dona by the executive routine $SXRQP or 
$SXRQF. These routines place the packet in the receive queue of 
the desired task and schedule the task for execution. $EXSQP 
queues the packet by priority. The alternate entry/ $SXRQF/ 
queues using first-in/ first-out logic. 

Note/ that the routines are used by the executive to 
interface to other tasks besides ACP's. For example/ this is 
the mechanism used to pass command lines to MCH and abort 
messages to TKTN. 

An AGP receives the packet by entering system state and 
removing the first entry from its receive queue- The logic 
necessary has already been discussed in section 3.5.1. 



5.6 TASX TERMI! 



The only other module in the executive 
ACP's besides ORQIO and 10308 is DREIF. 
the code used to clean-up the system data 
exits. A part of this clean-up is to check 
I/O is completed and all I/O processes have 



which is aware of 
This module contains 
bases when a task 
that all outstanding 
been terminated. 
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uie code for tiiasa steps starts at label 55. iB‘0.R£IF. The 
fir.3t step is to test for ojitstandiag I/O by testinq.;' T, IOC-. If 
tne value is nonzero/ $IO.KIL is called for each device assigned 
by the axitting task. 

Qnca the I/O count has been reduced to zero/ the logical 
unit table is scanned again for attached devices and I/O 
processes. Any attached devices result in an lO-DST packet 
being issued by the executive on behalf of the task. Similarly/ 
an I/O processes still active will result in an IQ.CLR packet 
being queued to the device. This is done by calling $ORQRQ. 
The packet should then be foraarded to the ACP and it should 
terminate the I/O process in a timely fashion- Qtherulse/ the 
task exit ulll not be coapletad- 

The test for an I/O process Is to check the second word of 
each logical unit table entry- If the lun is non-zeroy an I/O 
process is assumed. However/ if the lun is locked/ the lO-CLN 
function will not be issued- 




CHAPTER 6 



ACP SNABLINS/DI 0 A 8 LIMG 



An ACP must be enabled before it can be used for user I/O. 
Similarly, the reverse capability is usually provided. The 
common names for these operations are mount and dismount* This 
chapter aili discuss the requirements for ACP enabling and 
disabling and present five approaches that could be used by an 
ACP Impleaantatlon* 



6,1 EM ABLINS RSaUIREMENTS 



ACP enabling merely means satisfying certain conditions 
that allow user tasks to issue I/O requests to the ACP. For the 
Digital ACP^^s, enabling a device is performed by the MOO task. 

However, the MOD task is not the only method for enabling an 

ACP, Essentially, an ACP can be considered as enabled when it 

is servicing I/O requests from user task. The conditions that 

must be met to reach this state are as follows: 

1, The device is marked as mounted. The US,MOU bit in the 
device status byte of the 0C8 indicates if an ACP is 
mounted or dismounted. If the bit is zero, the ACP is 
considered as being mounted* 

2, The TCa address of the AC? is stored in U,ACP of the 
0C8. This value will be used when an I/O packet is 
queued to the ACP. The field will be assumed to be 
valid if 03, MOD iridicates the device is mounted 
(0S.MQ0=a), 

3, - The ¥C3 is allocated from the system, pool. The address 

of the yc.3 is stored in U.'lCB of the UCB, T,he first 
word of the 7C3 wil.i be used as a transaction counter 
and will be incremented when an I/O packet is queued to 
the ACP, The field will be assumed to be valid if 
OS, MOO indicates the device is mounted {US,MOO=0). 

4, The ACP has performed any operations necessary to 
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initial izs itself and the device. It has verified user 
I/O request aiii be legal for the devlca and the 
currant stata of the RSX-llM systaia. 

5. Flnali'/r the ACP is dequeuing I/Q packets froa its 
receive queue when they are queued to it by the 
executive* 



The logic rsecessary to reach the state listed above is very 
simple. The complexity of the Digital MOO task is because of 
the device initialization operations aiid command processing it 
performs and not the actual mounting of the ACP. For example/ 
when mounting a Files-11 disk/ MOO must read the fiies-11 data 
structures on the disk and setup all the information needed by 
FllACP for using the volume. 

Before an ACP can be mounted/ the current state of the 
system must be checked to see if conditions will allow the 
operation. Among the more common checks performed are the 
following : 

1- The device characteristics word (U-Cyi) in the UCB is 
checked to see if the device is mountable. If the 
device is not mountable (DV.MNT=0)/ the mount request 
is disallowed. 

2. The device status byte (G. STS) in the 0C3 Is checked to 
see if the device is already mounted. If the device is 
already marked as mounted (US-MMT=0)/ the mount request 
is disallowed. 

3. The device status byte (U. STS) in the UC3 is checked to 
see if the device is marked for dismount. If a 
dismount request is pending (US.MDM=1)/ the mount 
request is disallowed. 

4. The device DCB is checked to see if the device driver 
is loaded. If the driver is not loaded (D.DSP=0)/ the 
mount request Is dlsallowed- 

5. The system task directory is searched for the ACP. If 
the TCB is not found/ the mount request is disallowed. 

5.. The third status word of the ACP's TC3 is checked to 
sea if' the task was built as an ACP, If is waS' not 
(T3,ACP=0)/ the mount request is disallowed, 

7. The privileges of tna user are checked to see if he is 
allowed to mount the device. Typically/ if multiuser 
protection was selected and the user is nonprivileged/ 
he must own the device or it must be marked as public. 
Otherwise/ the user must be privileged in order to 
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Mount tise devica. 



Besidas. the cojaaion checks list above./ usually device and 
specific AC? checks Bill be made. ?or exafflpls/ if labeling 
in formation is available on the device/ it will be checked 
against user supplied values to insure the right volume is being 
mount ad. 

The other operation perforraed when an ACP is mounted is to 
process command options specified- A typical ACP will allow 
options which to be specified when it is mounted. The options 
override any defaults established at assembly and build time. 



In summary/ mounting an ACP involves determining if the 
mount request can be allowed/ processing any options/ and 
setting up the ACP to process user requests. A separate task 
can be used for this process/ the ACP can be self-mounting/ or 
some combination of the two approaches can be used- 



6.2 DISA8LIMG REQUIRSMEMTS 



Disabling an ACP reverses the process of mounting it. The 
same approach is followed. First/ the dismount request is 
validated/ any options are processed/ and the ACP is dismounted. 
An AC? is considered dismounted whan it is no longer marked as 
mounted for a device (5JS-MQU=l). Mhen ail devices serviced by 
the ACP are dismounted/ the AC? task axits- 

One point to note is that the actual dismounting of an ACP 
occurs asynchronously from the dismount request. Before the 
device can be marked as dismounted/ all outstanding I/O requests 
queued to the ACP must be completed and ail I/O process must be 
terminated- For this reason/ a mark-f or-dismount bit (US.MDM) 
is available in the U.STS byte of the OCB. Mhen this bit is 
set/ it signifies a dismount request has been made- The ACP 
will complete the process when all outstanding activity on the 
device is complete- Also/ no new I/O processes will be allowed 
to be initiated. 

The usual, approach to dismount an ACP is for a separate 
task to process the dismount- request from the terminal- and queue- 
.an IQ, DM0 packet to the ACP, Qnca tiie oacxat i.s racaived by the 
ACP/ it completes the process when ail activity fo.r the unit is 
finished. Digital's 9 MO task is an example of this process. 
The checks performed by OMO are typical for any dismounting 
process: 



1. The device characteristics word (D.CMi) in the OCB is 
checked to see if the device is mountable. If the 




ACP ENA8LIMG/DISABLING 



PAGE 6-4 



device is not raountabie (,D¥. the dismount 

caquest is aisaiioued- 

2. The device status byte (IJ.3T3) in the -3C3 is chackad to 
sea it the device is mounted-. If the device is not 
mounted (U3.MNT=l)jr the discount request is disalloMad. 

3. The device status byte (U.STS) in the OCB is checked to 

see if a disaount request is already pending. If a 
request is the disaount request is 

disallowed. 

4. The privileges of the user are checked to see if he is 
allowed to disaount the device. Usually/ the same 
checks performed for mount privileges are applied- 



Mhsn all checks are finished/ the disaount process sets the 

OS.MDM bit and queues an 10. OHO packet to the ACP. This packet 
is processed by the ACP in the following manner. 

1. The 10. DM0 packet is returned with the appropriate 

code. Usually/ this will be success 

2. If the transaction count in the VCB is used in the 

usually fashion/ it will indicate the number of 
outstanding I/O packets queued to the ACP and I/O 

processes. tihen the count reaches zero/ the ACP can 
complete the dismount process. Otherwise/ it continues 
to service I/O packets, reexaaing the transaction count 
after every packet is finished. 

3. The ACP is marked as not mounted (US.M0U=1). 

4. The mark-f or-dismount bit is turned off (US.M0M=0). 

5. The yCB is returned to the system pool. 

6. The Internal count of mounted devices is decremented. 
Mhen the count reaches zero/ the ACP can finally exit. 



5.4 3TMDARD. APPROACH 



Digital's solution to enabling and disabling ACP's is the 
MOO and DM0 MCR tasKS. The next two sections outline how these 
tasks functions and their applicability to ussr-wrltten ACP's- 
In general, the use of the MOD and DMQ task for user-written 
ACP's is not recommended because of the support problem for 
future releases of the operating system. 
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6,3.1 mis Task 



The M0« tasK supports mounting Fiies-li disks and ANSI 
magtapes. It also contains support for DECMgt Phase I, 
However, MOIi Is no longer used by OECHET. In addition, the 
RSX-llM ?3.2 version of MOO provides support for the /FOREIGN 
SHitch, This is intended to allow MOU to be used for FCP-styie 
ACP's. 

The flow through HOC is diagraaiaed in Figure 6-1. MOO 
consist of tao common modules used for all ACP's (MOURQT, 
MQ0PA8) and AC? specific parsing ana mounting routines. The 
overall approach to adding a new ACP is to cods a nea parsing 
and mounting routine and modify the dispatch points In MOO to 
correctly call these routines for the nea device. 



The task entry to MOO is in the module MOOROT, On task 
entry, an immediate dispatch is made to the entry $MPRSP in the 
module MOOPAR, The initial command processing performed by 
MQOPAR is as follows: 

1, The parameter area used by MOO is zeroed. This area is 
in MOOROT and is referenced throughout the task, 

2, The command line is input from the users terminal, 

3, The device to be mounted is parsed from the command 
line. The remaining switches are not examined at this 
point, 

4, Lun 2 of the MOO task is assigned to the specified 
device . 

5, The OCB address is retrieved from the LOT table and 
stored at label $MDEV- 

6, The device DCS is checked to see if the device driver 
is loaded, 

7, If the device is not a magtape (D¥,REC=0), the unit is 
attached. 



Onca the coiaaon command parsing is finished, the devica 
specific parsers are called from MQOPAR. The 0C3 davica 
characteristics are examined. to determine which device parser 
should be used: iPARll (Files-11), MPARMT (ANSI magtapes), or 

MPARCM (coaiiunications device}. If MOO is to be used' for a 
user-written AC?, the coda at this point will have to be 
modified to dispatch to the new AC? parsing module. 
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Tha parsing aodtiies perform basically the same operations. 

The f oiloaing- steps are perioraads 

1. The fCB is allocateii from the systeai pool. The address 
of the buffer is stored in and the size in 

$MVCBL. The initial ¥C3 is zeroed. 

2- The remainder of the cofflaand line is parsed for the ACP 
specific switches. 

3. The user privileges are examined to see if the user has 
the necessary access to mount the device- The check is 
performed by the routine $P¥T3T in the module M0TJPA8- 

4. If needed, the mount list entry is allocated and filled 
in with the users terminal GCB. The mount list entries 
are used for disks and do not need to be used for 
user-written ACP's- 



Mhen all parsing is completed, control is returned to 
MQUROT- Hare, some of the basic tests are performed and a 
dispatch is made to the device specific mount modules: MllOV 
(Files-11), MMTQV (ANSI magtapes), or MCMOV (communications 
devices). This is the second point modifications will need to 
be added to correctly dispatch for the new ACP. 

The actual device mount takes place in the device specific 
mount modules. The disk and magtape routines perform device I/O 
to read the volume labeling information. The best routine to 
use as an example is MCMQV. This routine has no device specific 
I/O and therefore can be more easily read. The usual processing 
performed for a device Is as follows: 



1. The system task directory is searched for the ACP'S 
TCB. 

2- The TCB Is examined to see if the task was built as an 
ACP. 

3. The I/O packet for the lO.MOU request is allocated from 
system pool and Initialized. 

4. The device is detached. 

t). The address of the ?C3 aliocatad previously is stored 
in the 3CB- 

6. The ?C3 transaction count is incremented. 

7. The device is marked as mounted by clearing US.MfiT. 

. The TCB address of the ACP is stored in the UC8- 



8 
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9» The 10. MOO xunction is queyed directly to the AC?. MOO 
is placed, into- I/O aai't and it increments, its. I/Q 
count. 



When the ACP coapiatas the 10. MOO function, it returns 
success /failure to MQU. The HQU task then cleans up, outputs 
any voluffle information, and exits. 



6,3.2 MOU /FOREIGN 



A new feature of MOO in RSX-llM V3.2 is the support of the 
/FOREIGN switch. This switch allows user-written ACP's to be 
enabled for devices. Onf ortunately, the impleaentatlon is not 
easy to follow. However, the feature does provide a mechanisis 
for mounting user-written ACP's without aodiflng MOO or writing 
any new code. If used, the MOO sources should be studied to see 
how the switch affects the normal processing performed by MOU. 



6.3.3 DMD Task 



The DM0 task consists of one module, DISMMT, The procedure 
for dismounting a device is much simpiier. In some cases, the 
DMQ task may be used for user-written ACP's without 
modification. 

The flow through DMQ begins at the task entry, $DMGEP. The 
processing is as follows: 

<To be written> 



6.4 NON-STANDARD APPROACHES 



As stated before, the use of the Digital MOU 
is not recommended for user-written ACP's because 

proDleiii from release to raiaasa of the operating 
f ollowing a-p'pro aches can be used i-nstaad. 



and DM0 task 
of the support 
system. The 
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6. 4. 1 Self-Initial Ization 



The easiest iaethoa of ini tializing. an ACP is for it do the 
mounting itself «hen it is first sciiaduled* This approach is 
appropriate for AC?"s yhich service only one device driver and 
involve no option processing. The ACP can allocate the 
setup the UCB status as needed# and perfora any device 
initialization- Once mounted# the initialization code can be 
oversjrittea as data space. Another possibility is to place the 
initialization code in an overlay segment. 

Usually# when this approach is used# the AC? is essential 
to the operation of the device and there is no reason to every 
dismount it- Therefore# the disabling step can be ignored* 



6-4-2 Driver Initialization 



A alternative to the AC? self- initialization approach would 
be for the device drivers serviced by the ACP to initiate the 
mount- If the UC-PMF bit is set in UC8# the power recovery 
entry in the driver is called when the system is booted or the 
driver is loaded- This entry can be used to start the mount 
process- Either the driver can set the necessary status 
directly or it could queue a IQ- DM0 packet to the ACP and let it 
finish the operation. 

The same disadvantages apply to this approach as for the 
previous section. There is no convenient method for dismounting 
the ACP and inputting mount-time options- However# the approach 
does allow several different drivers to each mount the ACP 
separately for themselves- 



6-4-3 Alternate Task 



A final approach Is to implement new system tasks to 
specifically mount and dismount the user-written ACP- The tasks 
can be modelad after tae MOO and OMQ tasks- The new tasks can 
perform any special processing.: required* The. major advantage of 
tti.is approach is the indepeade.nca gained from future Digital 
modifications to 100 and DMQ- 

This approach was used by OECIST to mount METACP and set up 
the other software- The sample EMA and DIS programs distributed 
with this manual can be used as a basis for the ACP specific 
enabling and disabling tasks- 




CHAPTER 7 



aCP IMPLEMEMTlflOI 



This chapter covers some of the basic considerations of ACP 
impleiBentatlon- The Material is not exhaustive and will not 
apply to every ACP, All ACP implementations will be different 
and no fixed set of guidelines can govern how an ACP will 
function internally. 



7.1 TASK ATTRIBUTES 



ACP's are constrained by the limits RSX-llM places on 
privileged tasics. RSX-llH associates a set of attributes to 
each task in the system. The proper definition for each 

attribute will have to be decided when the ACP is implemented. 
Some of the attributes iavolve trivial decisions: the 

partition#^ taskname/^ etc. Others are more important and are 

discussed in the following two sections. 



7.1.1 Task Mapping 



The major task attribute to be considered is the ACP task 
mapping. Figure 7-1 diagrams the mapping for a privileged task. 
The first four APR's (APR0-APR3) are always mapped to the 
executive, APR4 is mapped to the executive if 20K executive 
support was selected whan the system was generated. If the AC? 
is to be portabls between systamsr APR4 should not be used. 

'lorjaally,.- the ACP is then left with APRS and^ APR6^ to map 
its task code and APR7^ to map the I/O page. If 8 KM is not 
enough memory,/ the AC? can extend into the I/G page. However/ 
when a switch is made to system state/ the executive will unmap 
the ACP's APR7 and map the I/O page. If the top of the ACP is 
used for data and not code, this restriction will usually not be 
a problem. 
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Figure 7-1 
TASK MAPPIMG 



7.1.2 Task Build Requirements 



When linking the ACP, several TK8 options apply. First, 
the task should be declared as an ACP with the /AC switch. This 
TKB switch causes T3. ACP to be set in the TCB when the ACP is 
installed. When T3.ACP is set, the executive prevents sends to 
the ACP task. This is desirable because the AC? is receiving 
the I/O packets on its receive queue and would have trouble if 
some other task were allowed to send it messages. The /AC 
switch is also useful for identifying the task as an ACP when 
the device is mounted. 

The /AC switch also causes the task to be marked as 
privileged. The other TKB switches used can be set according 
the ACP imp lamentation. 

There are no special TKS options that apply strictly to 
ACP's. Therefore, the options specified will be a function of 
the ACP implementation and the environment the AC? will be 
executed in whan it is mountad,: One consideration is whether to 
usa a separata partition for the AC? other than the one used far 
user tasks. A iock-out condition can occur- if a- user task 
issues an I/O request to an AC? ahicn is swapped out because of 
the user task- 
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7.2 DESIGN CONSIDER ATIOMS 



This section comments on some general design considerations 
for ACP''3 Tile list is not axiiaustiya and has been developed from 
past experience in writing ACP's. 



7.2.1 ACP I/O 



Besides receiving I/O requests from user tasks, ACP's 
usually issue I/O request. These request can be to device 
drivers or to other ACP's. Moraally, the AC? would use the QIO 
directive for any I/O it needs to perform. However, when 
perforfflance is an Issue, the ACP can bypass the normal executive 
directives and interface directly to the drivers. In 
high-performance environments, the ACP and the driver may 
actually use cooperating code and bypass RSX-llM altogether. 
How an ACP performs its I/O using non-standard logic is strictly 
up to the implementation. 



7.2.2 Transportability 



Often, an ACP is required to run on a variety of machines. 
The AC? coding can be greatly simplified if the ACP is 
restricted to one type of machine. However, by using 

conditional assembly symbols and interfacing correctly to the 
executive, it is possible to write an ACP that will properly 
function on all PDP-11'’s- 

The biggest difference between aachines is the presence or 
absence of memory management. Typically, any code used to move 
information between the ACP and a user task must be assembled 
with conditionals for memory management. Gn a mapped system, 
the APR's must be manipulated. On an unmapped system, the 
entire system can be addressed directly. The problem can be 
avoided by using the executive routines to manage data 
transfers. 

The other large difference^ between machines is arithmetic 
instructions. The older PDP-ll's do not have the MDL/0I7 

instructions. If tr ansportabiit y is desired to such machines, 
the executives $0I7/$MtJL routines should be used. 
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7,2,3 Pool Otilization 



Host RSX— IIM systems suffer from a lack of pool* ACP's are 
a potential large user ot pool. Limits on the aiBount of pool ,an 
ACP can use ana use of internal versus system pools should be 
considered in the design of an ACP, 

The typical approacft Is to create an internal AC? pool that 
is structured the same as tne RSX-llM system pool. The size of 
the pool is a mount or link-time option. Whenever the ACP needs 
to ailocate an internal structure/ an attempt Is first made to 
allocate from the AC? pool. If this fails/ the allocation is 
attempted from the system pool. Mhen the structure is 
deallocated/ the address indicates to which pool the memory is 
returned. 



7.2.4 AGP Variables 



The design of an ACP should consider the amount of 
flexibility that will be built into the code. There are four 
types of ACP variables: asseably-tirae statements/ TKB switches/ 
mount-time options/ and rtin-time I/O functions. For example/ an 
AGP may use a separate LUN for each I/O process it supports. A 
TK8 option would specify the maximum number of luns the ACP can 
use. A mount-time option would then specify the number of 
actual luns to be used (up to the taskbuilder limit). 

A good practice is to make the defaults for each option 
settable by the taskbuilder GBLPAf and GBLSYM commands. This 
allows each installation of the AGP to specifically configure 
its default options. 



7.2.5 Parforaance Statistics 



If the ACP supports options/ it should then accumulate 
statistics on its parforaance. This would allow adjustment of 
Che options to maximize- perforiaanca in a given environment. 
Without statistics/ the users of the ACP will be faced ?iilth a 
situation similar to 71IACP, There are many switches for 
mounting a aisk. however/ except for ayeballing the system 
performance/ there is no way to tell how a particular option is 
pert orming. 

If performance measurements are used by the AC?/ it the 
performance code should be conditionally assembled. This would 
allow a smaller version of the ACP to be assembled after 
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sufficiant axperience with the various options is- ootained. In 
ad-aition# some- method of examining the statistics, is. needed. 
This can be as simple as using the MCR OPEN cofflaand to exaaina 
xnoHn locations, in other cases#- the ACP may support I/O 
functions to return is performance data. One final method is to 
keep the performance data in the system pool and lapleaent a 
separate task to access the data and print reports. 



7.2.6 Serial Versus Parallel Processing 



The final consideration in the design of the ACP is whether 
it will process user I/O requests In serial or parallel. A 
serial ACP will only process one I/O request at a time. This 
greatly simplifies the implementation because only one set of 
Internal data bases needs to be kept and the flow through the 
ACP is completely synchronous. The ACP only attempts to dequeue 
an I/O request from its receive queue when it has finished the 
previous request. FllACP is implemented as a serial ACP. 

The serial approach is appropriate for ACP's which service 
fast devices such as disks. There will be little delay for ACP 
I/O The disadvantage of the serial approach is that the ACP is a 
bottleneck in the I/O mechanism. 

An ACP which allows parallel processing of user I/O 
requests will typically support one I/O request for each I/O 
process. Such an approach is particularly applicable for ACP's 
wftich service communication devices. I'lETACP is an example of a 
parallel implementation. There is a significant delay between 
the time the user DECNET QIO is Issued and the necessary NSP 
protocol has been exchanged to fulfill the request. 

However^ this approach is much more complex to implement. 
Many of the data bases and variables used by the ACP will have 
to be duplicated for each I/O process. In addition# the logic 
of the ACP must be able to save the context of one operation 
when it reaches a checkpoint# process another I/O function for 
another process# and eventually resume the original process. 
This requires the ACP coda to be reentrant and some sort of 
internal scheduling algorithm to be Impleaented. 



7.3 DEBUGGING MOT 






Because ACP's usually involve complex logic to implement 
their protocols# much of the time spent in development will be 
devoted to debugging. In addition# because bugs in the ACP are 
likely to corrupt the operating system# the stability of the 
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aacaine for other users Mill be raducea, 

0ns advantage of ACP's is that ODT can be used on the task 
portioTvS of the liap leraentation. However^ QDT cannot be used to 
breakpoint witain portions of the ACP code that run at systea 
state. In such code^ XDT aould have to be used. Siaiiarly^ XOT 
would have to be used for debugging any driver or executive coda 
involved with the ICP. 



Anotnar problera in developing ACP's occurs if the AC? 
terminates abnormally while still mountad. The data structures 
still mark the ACP as being mounted and the typical method to 
clean them up is to reboot the system. One alternative to this 
approach would be to write a special privilege task that 
destroys the ACP data structures to the point where you can 
remount the ACP. While some pool may be lost^ the basic 
integrity of the system can be preserved. 




CHAPTER 8 



SXSCUTIfE SERVICES 



There are many executive services an ACP can use. This 
chapter briefly describes some of the services available from 
the executive. There are many other facilities which are not 
documented in the chapter. The actual calling sequences for the 
routines can be found in the executive listings. The routines 
are also documented in the RSX-llM System Logic Manual. 



8.1 SYSTEM STATE 



Before an ACP can use an executive service or manipulate 
system data structures# it must make sure its access to the 
executive is correctly sychronized with other system activity. 
This is done by switching to system state. Once a switch to 
system state is laade# the ACP is running as a part of the 
executive and must follow all rules applicable to the kernel 
state. For example# directives cannot be issued from system 
state and any unexpected trap will cause the system to crash# 
rather than aborting the ACP. 

The switch to system state is accomplished by issuing an 
SMT 376. This instruction is followed by the address to return 
to when a return is made to task state. The following 
summarizes the switching to system state process; 

Call By; CALL $SM3TK#addr (R3XMC.MAC) 

Generates; EMT 376 

.HQRD addr 

Returns to next instruction 
Switches to xernei mode 

Maps user APH's 4<?)#5#6 to xernei space 
Kernel APR's 0,1#2#3#4(?) mapped to executive 
Kernel APR 7 mapped to I/O page 
Saves all registers 



Effect; 
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Exit By; RETURM instructioR. Exit is to "addr.^*^ 

Pre-kernel registers., restored-' 

Values can be returned in iiO-R3 by storing value 
in 2(S?) to 10C3P) before RETURN, 



3.2 I/O TERMISATIOM 



One service used by ACP's is I/O paclcet teraination. The 
I/O termination code is located in the executive module I030B. 
Three entries are provided by the executive; $IODOS^ $IOALT^ 
and SIOFIM. The first tao entries are used by device drivers. 
In addition to the I/O packet termination^ these routines free 
the device for the next I/O packet- The $IOfIN routine is the 
entry usually used by ACF's as it does not affect the driver 
data bases. 



8.3 ADDRESS CHSCKI?iG 



Another service provided by I0SU8 is address checking. 
Mhenever an address is passed from a user task to an ACP/ it 
must be checked by the executive to wake sure the address is 
aithin the boundaries of the user task- This check must be done 
in the context of the user task- Thera fore, address checking 
must be performed before the I/O packet is queued to the ACP- 

The executive provides five entries for address checking. 
The first three^ $ACaKPr SACHKM, and $ACHK2, are only used for 
directive processing and do not return errors to the caller. 
Instead/^ they return an directive status error if the address 
check failed. 

The two entries used for I/O-related address checking are 
$ACHKB and $ACHCK- The first entry checks for proper byte 
alignment- The $ACHCX requires word alignment. The routines 
return with the carry bit clear/set as a success/failure 
Indicator. 



8.4 ADDRESS RELaClTIQri 



In order for an ACP to address a user-task address on a 
mapped system, the user-task virtual address must be transformed 
into a relocation bias and offset. As in adoress checking^ this 
process must be performed in tne context of the user task- 
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Two entries In IUS08 provide sriopoct for address 
reiocation. The- first^ routlB-eir: SRELQC^,. transforias the- user- 

virtual address into a relocation bias to be loaded into AF86 
and tlia APR6 disp lac ament. These values can then be passed to 
the ACP/ wnich can than use them to map the user task addresses. 

The second routine is named $SELQM. The routine in 

addition to performing the address relocation^ loads kernel APRS 
with the address bias. This routine is used by the executive 
and/or drivers Mhan processing an ACP I/O request and 
reading/aritlng user-task jaesaory . 



8.5 BUFFER ALLQCATIOM 



The executive module CORAL contains support for buffer pool 
allocation. The routines are normally used to allocate and 
deallocate space In the system pool^ houevery they can be used 
to manage any buffer pool uhich follows the RSX-llM system pool 
mechanism. The System Logic Manuals provide details on this 
mechanism. 

Two entries in CORAL can be used for buffer allocation* 
The $ALOCB entry is the general system pool allocation routine. 
The $AL0C1 is an alternate entry. Herey the buffer listbead 
address is passed to the routine instead of defaulting to the 
system pool as in $AL0C3. 



MOTE 



The SALCLK (allocate clock queue entry) and $ALPKT 
(allocate I/O packet) should not be used by ACP's. 
These routines return a directive status error if the 
allocation fails instead of an error return to the 
caller. 



3.5 BUFFER OEALLGCATIGN 



CORAL also provides two buffer deallocation entries. 
$D£ACB is the general system pool deallocation routine. $D£AC1 
is the altarnata entry for general deallocation of buffers for 
non- system pools. 
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3,7 Q 0 SO E A 1 P OL AT IO.M 



The ffloduie QUEUE provides a variety of entries to 
manipulate the various RSX-llH queues. The most used entries- 
are $3IiiSF, $QINSP, and $QRM¥F. The first two routines 

respectively insert by first-in^ first-out or by queue entry 
priority. When priority insartion is used/ byte 2 of the queue 
entry is assumed to contain the priority. 



$QRMVF removes the first entry in the queue. This routine 
is used by all ACP's to remove I/O packets from the receive 
queue. It may also be used for internal ACP queues or other 
RSX-llM data structures. 



8.8 DATA TRASSFER 



The module BFCTL contains an extremely useful routine for 
passing data between ACP's and the user task. The routine 
SBLXIO moves a block of data between any two points in a mapped 
system. It is called with the number of bytes to move/ the 
source APRS bias and offset/ and the destination APR6 bias and 
offset. 



iOTE 



The other routines in this module are for device 
driver usage. They expect the UCB to be set up and 
should not be used by ACP's. 



8.9 TASK SCHEDDLING 



The last executive services commonly used by ACP's are 
found in the module RSQ38. The routines in this module perform 
task scheduling. The most useiui entries are- ;$HX-R<3F, .$£X8QP/ 

and $EX8QM» These routines p-ass an I/O packet to the receive 
queue of the requested -task' and. schedule the task- toe execution. 
If the task is »not active/ it is run for the first time, 
Otharvisa/ the task is unstopped and potentially becomes 
available for ax-ecution. 

Another useful routine is SSTPCT, This routine stops the 
current task and is used by ACP's to stop themselves when they 
have no work to do. Mote/ when called at system state to stop 
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the 4CP./ the routine aarelF aarics tne- AC? TCB^ as- being stopped* 
The actual rescheduling does not occur until the- ACP- exits 
system state* 




APPENDIX A 



REAOIMGS/REFERENCSS 



This appendix lists docuaents that anyone «ritlng an ACP 
should be familiar Hlth« It is impossible to present an 
exhaustive list because "everything" one needs to know to urite 
an ACP is an intimate knowledge of the system- 



A.l DIGITAL MANUALS 



The following is a list of the most relevant SSX-llM 
manuals- No single manual deals with the subject of ACP*s. In 
fact, the manuals contain little information directly applicable 
to ACP's- The information concerning ACP's must be extrapolated 
from descriptions of other subjects- 



A-1-1 RSX-llM Executive Reference Manual 



This manual describes the available executive services and 
system directives- It also presents some material on the 
structure and design of the operating system- 



A- 1-2 RSX-llM Crash Dump Analyzer Reference Manual 



This manual describes the use of the Crash Dump Analyzer 
(CDA) utility, ihile the ACP implementor will certainly become 
vary familiar with crashes, the most valuable section is 
Appendix a which list the system data structures and symbolic 
offsets- 
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A»1.3 lAS/RSX-li I/O Operations Refarenca Manual 



This manual describes the use of the File Control Services 
(PCS), including dlagraas of the FCS data structures* The 
manual is only important to someone interfacing an ACP to FCS- 



A.1-4 I13/RSX-11 RMS-11 Programmer's Reference Manual 



This aanual describes the use of the Record Management 
Services (RMS). However# it contains no information on RMS 
internals or data structures. The manual is only important to 
someone interfacing an ACP to RiMS. 



A. 1-5 RSX-llM I/O Drivers Reference Manual 



This manual describes each RSX-llM I/O driver and the 
format of the I/O reguests serviced by each driver. The 
appendices contain useful sumaaries of all Digital defined I/O 
requests and error codes. 



A. 1.6 RSX-llM Guide to Mritlng an I/O Driver 



This manual contains the information necessary to write an 
I/O driver. It also presents the best description of the 
overall I/Q process- It contains descriptions of the I/O data 
bases and basic I/O flow- This manual is a good starting point 
for anyone considering writing an ACP- 



A.1.7 RSX-llM System Logic Manuals 



This two-volume set is not Included in the RSX-llM 
documentation kit. However# it should be considered a “must” 
purchase for implementing an ACP- The set contains information 
on the structure and design of RSX-llM. It also includes 
descriptions of all executive modules and data bases. 
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A. 2 SOURCES 



The final authocify on SSX-llM is the source listings, the 
RSX-llM binary distribution Icit includes the sources for the 
executive^ device drivers# and MCR- The utility source kit 
supplies sources for all utilities# FCS# FllACP# and the macro 
libraries. 

The sources are very uell Mritten- This section oentions 
the most useful modules. 



A. 2.1 Executive Sources 



A complete listing of the executive should be available 
before aritlng an AGP. In particular# the follouing modules 
should be read: 

1. DRQIQ - This module contains all the QIQ processing 
code# including the executive ACP processors. 

2. IQSU8 - This module contains all routines related to 
I/O. 

3. DREIF - This module contains the code related to task 
exit- Of interest to the ACP writer is the code 
relating to I/O cleanup. 



A. 2- 2 Sources 



The sources for the MOU task are found on the RSX-llM MCR 
source disk in UIC 1112# 103. The following modules comprise this 
task. 

1- MOUROT - This module is the root for the task. It 
contains the dispatching code for the mount process and 
the error handling code. 

2- MOOPAR - This module is the general parser for the 
task. It determines the device name specified in the 
command line and dispatches to the appropriate 
device-specific parser. 

3. MPARll — This module is the command line parser for 
Files- 11- 
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4. 


MPARMT - This module is 
AM3I magtapes. 


the 


command 


line parser 


for 


t) m 


MPARCM - This module is 
DECNET Phase I. 


the 


command 


line parser 


for 


6m 


MllOV - This moduie 
Files-11. 


is 


the mount 


processor 


for 


7. 


MMTO? - This module is 
magtapes. 


the 


mount processor for 


ANSI 


8. 


MCM0¥ - This module is 
DECJIET Phase I. 


the 


command 


line parser 


for 



9. MOTSOV - This Module displays the volujae attributes. 



A. 2.3 DM0 Sources 



The OMO task source is the moduie DISMHT.MAC. This file is 
found on the MCR source volume in UIC C12/10J. 



A. 2.4 FllACP Sources 



FllACP is the one Digital AGP for which sources are 
available at most sites. The ACP sources are found in DIG 
£13,101 on the MCR/FCP source disk of the RSX-llM V3.1 kits. 
The source code was omitted from the RSX-llM V3.2 distribution. 
Perhaps the most useful file is DI3FAT.MAC. This module 
contains the I/O packet degueuelng and dispatching code- 



A.2.5 DECNET Sources 



The DECMET sources are another example of an AGP. However 
the sources are only available by purchasing the DECNET sourc 
kit. 



(0 % 
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A.2.6 FCS-11 Sourcas 



Tna FC3 sourcas ara found on tiie RSX-llM utility source kit 
ia UIC t'SQflQl, If ?CS must be modifiad to use your ACP^ this 
kit should be purchased. FCS is very old and not uritten to the 
standards used for other code. The reader will find that the 
coda Jumps around considerably and is difficult to follow. One 
vary useful way of listing FCS is to make a concantenated 
listing. The sources contain directions for doing this. 



A. 2. 7 Other Sources 



The R3X-11H source distribution kit contains many other 
useful modules. Among the most significant are the following: 

1. C32,10 3 - PIP sources. 

2- C 55/ 101 - Command line routines <GCML/ CSl). 

3. C60/103 - PIP utility (PIPUTL) sources. 

. £66/ 103 - Macro definition flles- 
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DATA STROCTURS DETAILS 



This section details the features of data structures of 
interest to the ACP implementor. Only the fields of Interest to 
ACP's are discussed in this document- Further information can 
be obtained from the references listed- A diagram is presented 
for each structure^ along with information on which macros and 
files define the symbolic offsets^ values, and bit masks. 



NOTE 

The macro definition files refered to are located on 
the RSX-llM Utility Source kit in UIC C66,10l- A 
listing of these files is a very valuable reference 
tool- 

The global definition file is the file used to create 
an obgact module containing the symbols defined as 
globais. 



8-1 QIQ DATA STRUCTURES 



The QIO data structures structures are used to hold the I/O 
parameters and route the request to the correct device- The 
structures in this catagory are the QIQ directive parameter 
block#. the I/O packet, and the yindom block portion of the- task; 
header . 
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1 =============================== I 

00 1 12. 1 Die I 

j I 

02 1 I/O Function Code I Q.IOFM 

j 1 

04 I Logical Unit Number I Q.ICLU 

1— I 

06 I Priority I EFU ! Q.IOEF 

} } 

10 1 I/O Status Block Address 1 Q-I0S8 

I 1 

12 I AST Address I Q.IOAS 

j 1 

14 i i Q-IGPL 

I j 

16 1 i 

1 1 

20 I I/O Parameters I 

i 1 

22 I I 

I j 

24 ! 1 

26 i I 

j ============================== j 



Symbol Definition Macro; 
Macro Source Fiienaffle; 
Macro Library Filename: 
Global Definition File: 
Object Library Filename: 



«DPB$ 

RSMDIR.MAC 

RSXMAC.3ML 

DIROEF-MAC 

SYSLIB.OLB 
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Figure 8-1 
QIQ 0P8 
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3«1.1 aiQ Directive Parajaet-er Slock 



The ■ user task constructs a QIO directive parameter block 
(DPS) and issues a QIO directive whenever I/O is to be requested 
from a device, this includes. I./ Q requests to ACP's. The QIQ 

DPB is noraally constructed by the 910$ and QIQM$ macros. The 

iorraat of the QIO DP8 is shown in Figure B-1. 

The folio wing f ieid.s in the QIQ DPS must .be considered when 
writing an AC?: 

a.IOFU The I/O function is split into two bytes. The high 
byte is the function code and must be from 

0-31(10). This is the value which Is used by the 
executive to determine the action to be taken for 
the function. The low byte is the function 

modifier. It is not processed by the executive but 
Is passed to the driver/ACP. 

The choice of I/O functions will depend on whether 
a DCP or OCP is being written. DC? typically use 
an existing set of function codes (such as 

Files-11). Jlote^ DCP's require all iCP function 
codes to be greater than or equal to seven. In 
fact/ $GTPKT assumes all I/O request with codes 
from 7-31(10) issued to a device with an ACP 

enabled are ACP functions and dispatches them to 
the ACP. 

yhen writing a OCP/ it is wise to choose a function 

code that is not used by other drivers and ACP's. 

If a I/O request is issued to the wrong device/ 
this prevents unexpected operations from occurlng. 
The modifier byte can be used to separate a class 
of I/O functions into separate requests. 
Currently/ all function codes but 31(10) have been 
used by Digital. However/ codes above 24(10) are 
used only for specialized functions for 

communications devices and real-time interfaces. 

Q.IQPL How the I/O parameter words will be used by an ACP 
is ACP dependent. The only constraint on this set 

of par a me tars, is that' for transfer functions the 
first parameter must be a buffer address and the 
Q. .rOPL^2 must be the buffar size In; bytes. 



References: 



R3X-11M Executive Reference Manual/ pages 6-90 to 6-94. 
This section documents the format of the DPB and how 
to setup the QIO macros. 
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RSX-"11±M Guide to- spiriting a Device Oriver^ pages 4-6, jr 4-7. 
This^ section docucs-ants the- forgiat- of a DPS.- 

RS.X-11M I/Q Drivers Refarenc.e Mantiai. This aamiai 
documents all current^ de'vica driver QIC functions and 
t-heir associated parameter lists. Qf particular 
interest are Appendices A and B which siuaaaries the 
QIO's^ their parameters, and tne various error codes. 

IAS/R-SX-11 I/O Operations Reference Manual, Appendix I. 
This appendix contains a listing of QIQSYM.HAC. This 
file defines all I/O function and error codes. 

fiSX-llM System Logic Manual, ¥oiuffle 2, pages C-41 to C-45. 
This section documents the various macros used to 
create QIO DPB's and issue the QIQ reguest. 



B.1.2 I/O Packet 



The I/O packet is constructed by the executive from the 
information in the QIO directive parameter block. The I/O 
packet is then dispatched to the proper service routine. If an 
AGP is enabled for a device, the service routine is the AGP. 
The format of the I/O packet is shown in Figure 8-2. 

ACP's are concerned with the following fields in an I/O 
packet. In general, the I/O packet should be considered to be 
read-only. The only axcaptions are the function code and 
parameter fields. These can be changed when the AC? is 
reformating the request and forwarding it to a device driver. 

I.TC8 This field contains the TCB address of the 
requesting task. The AGP may store this address 
away for further reference. 

I.LM2 This is a very important field for ACP's because it 
contains the address of the address of the window 
block (sea next section). Mote, that this address 
cannot be saved but should be obtained from each 
separate I/O packet. Task headers may be destroyed 
-and racr-aatad during task-- execution. In general, 
only the TC.3 address can be- saved b'y- an AGP for a 
task with an -acti've cannact-ion. 
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1 ===============—============== I 

00 I Link to Mext I/O Packet I I.LMK 

j 1 

02 1 EFJi 1 Priority 1 I. PHI I>£FM 

} j 

04 1 TC3 Address j I.TC3 

j 

06 1 Address of Second LUT liord ] I«LIi2 

I , 

10 I Address of Redirect OCS J I.UC3 

I J 

12 I Function Code J Modifier } I.FCN 

1-.^ J 

14 I Virtual Address of IQS8 1 I.IOSB 

I J 

16 1 Relocation Bias of lOSB I 

J 1 

20 1 Real Address of lOSB 1 

I j 

22 I Virtual Address of AST I I. AST 

I 1 

24 / / I.PHM 

/ Parameters (3 Mords) / 

/_ _ / 

44 I-LGTH 

Symbol Definition Macro: PKTDF$ 

Macro Source Filename: PKTDF -MAC 
Macro Library Filename: SXEMC -MLB 
Global Definition File: EXEDF -MAC 
Object Library Filename: EXSLIB.0L8 



Figure 8-2 
I/O PACKET 
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I-L.M2 can also be used to obtainad the original UC3 
address for the iun- The previous location^in the 
logical unit table is the original iun» The 
redirect cnain is folioued for every QiO request 
and the final UC3 address is stored in I,UCB« 

I.FCN This Is the I/O function issued by the user. It is 
copied fro^ Q. luFl of the QIO OPB. 

I.PRM These are the parameters for the I/O request. Mote 
that eight words are available as opposed to the 
original six in the QIO OPB. Except for these 
fields^ common code is used to fill in the I/O 
' packet. The parameter fields are established from 
the QIO parameters according to the type of 
request. 

For control functions, the six QIC parameters are 
copied unmodified to the first six locations. For 
transfer functions, the buffer address doubleword 
is placed in I.PRM+0 and I.PRM+2. The remaining 
five parameters are copied into I.PRM+4, I.PRM+6, 
etc. 

For ACP's, the QIO parameters are specially 
processed and the results stored in the 1/0 packet. 
All addresses passed as parameters must be address 
checked and relocated before the packet is queued 
to the ACP. In the case of a DCP, this processing 
takes place in DRQIQ. For UCP's, the packet is 
processed as a control function by the executive 
and passed to the driver without queueing. The 
driver then performs the necessary checking, sets 
the I/O packet parameters and send the packet to 
the ACP. 



References; 



RSX-llM Guide to Writing a Device Driver, pages 4-2 to 4-5. 
This section documents the various fields in the I/O 
packet. 

SSX-llM Guide to Mr i ting a Device Driver, page C-16. This 
section, documents the- -lacro ?KTDF$. This ..macro- is 
used . to declare the^ I/O . packet- symbolic offsets. 

R3.X-11M Crash -Dump Analyzer Hanuai, pages -3-.39 to B-41. 
This section documents the macro ?STDF$. This -macro 
is used to Jaciara the I/O pacxat symbolic offsets. 

S3X-11M System Logic Manual, ¥oluais 1, pages 3-30, 8-31. 

This section documents the macro PKTDF$. This macro 
is used to declare the I/O packet symbolic offsets. 




DATA STRUCTURE DETAILS 



PAGE 8-7 



J =============.=:=:=:==============::= | 

74 I Sumbec of LUH's J a*RLON- 

I — I 

76 I UCB Addrass. j' H.LUM 

I Windoy Address |L| 

I — J 

i 1 

I Reiaaining Eatries I 

I - 1 

1 I I 

I . 1 



Syrabol Definition Macro: 
Macro Source Filename: 
Macro Library Filename; 
Global Definition File: 
Object Library Filename: 



HD RDF $ 
HDRDF -MAC 
EX EMC -ML8 
EX EOF -MAC 
EXELIB-OLB 



Figure 8-3 
LOT TABLE 



B-1-3 Logical Unit Table 



Tile logical unit table (LOT) is used to datarisine to whicb 
device the I/O request is directed. It is also used by ACP's to 
establish a logical connection between a specific LOM in a 
specific task and a I/O process (such as an open file or a MSP 
logical connection)- A diagraa of the LOT table Is shown in 
Figure 8-3- 

The LOT table is located in the task header^r beginning at 
offset H-LOi- The previous location/ O-MLOI/ contains the 
number of entries in the LOT table- The LOT table consist of a 
series of two word entries, one entry for every possible LOM 
number the task say use- The first word of the entry is the OCB 
of the assigned device- Mote, this is not the redirected OCS. 

The second word is used Cor the window- block address- This 
is the structura wnich is used to - link a LUl to an AC? process-. 
T,hls word also serves two other purposes- The low bit is 
refer ed to as the lock bit- If this bit is set, another I/O 
request cannot be i-ssued on the LUM, The executive backs up the 
issueing task PC and places it in a wait-for-signif leant event 
state if such a request is issued- This is very useful when an 
ACP must enter a state where another I/O packet cannot be 
processed until the current request completes- 
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SOTE 

Only QIQ's ara affectsd by the lock bit* Any packet 
in the AC? queue foe the locked iun can be dequeued by 
the ACP. la order to aff ecti^eiy iock a lanjr the bit 
mat be set during the I/O packet processing prior to 
queueing to the AC?« 



The final use of the second aord is to notify ACP's about 
abnormal task termination yhen it has an active process for a 
iun- If the second aord of the LOT entry is non-zero (axclusive 
of the lock bit), a lO-CLM (code 3400) Mill be issued to the ACP 
by the executive task termination routine* 



3.2 DEVICE DATA STRUCTURES 



The device data structures structures are used to describe 
a generic device type, each unit, and each controller. The 
Device Control Block (DCB) names the device and contains the I/O 
dispatch tables. One Unit Control Block (OCB) exists for each 
device unit and forms the data base necessary for handling one 
I/O request. The Status Control Block (SC8) is used to 
coordinate activity among device controllers. 



S.2.1 Device Control Block 



One device control block (DCS) is created for each generic 
device type. The DC3 supplies the device name, points to the 
device unit structures (UCB's), and controls how I/O functions 
will be processed for the device. It is the function mask 
fields (D.MSK) that are important to the ACP writer. 

In general, DCP's will set the appropriate ACP function bit 
masks. Mhen DRQIO matches the function against this field, the 
special processing code for ACP's is then used. UCP's, on the 
otherhand/ yill mark its functions as control functions. 
Saction 4.2.1 discusses now the DCS fields saould be setup in 
more detail. 

References t 

RSX-llM Guide to writing a Device Driver, pages 4-8 to 
4-15. This is a location by location description of 
the DCB. It is oriented to device drivers. 
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I ============================:=== j 

00 I Link: to Mext DCS 1 O.Ll^K 

I I 

02 1 First OCB Address i D-UCB 

04 I Device lame I D.NAM 

} j 

06 I High Onit # | Lou Unit # | D.ONIT 

10 ] Length of an GC8 1 D.OCBL 

12 I Driver Dispatch Table Address f D.DSP 
14 I Legal Function Mask (0-15) | D*M3K 

1-^ j 

16 ! Control Function Mask (0-15) | 

I 1 

20 I HQP'ed Function Mask (0-15) | 

J 1 

22 1 ACP Function Mask (0-15) | 

I j 

24 I Legal Function Mask (16-31) \ 

j ^^^1 

26 } Control Function Mask (16-31) I 

30 1 MOP'ed Function Mask (16-31) 1 

32 I ACP Function Mask (16-31) I 
34 1 Driver PCS Address 1 D.PC8 



Symbol Definition Macro: OCBDFS 
Macro Source Filenaflie; DCBDF .MAC 
Macro Library Filename: EXEMC .ML3 
Global Definition File: SXSDF .MAC 
Object Library Filename: EXELIB-0L3 

Figure - 3-4- 
DCS 
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8SX-11M Guide to ariting a Davica; Driver/ page- C-5« This 
section docuaents. the aacr-o DCBDF$« This . aacro i,s 

used to deciara the DCS sysaboiic offsets* 

R3X-11M Crash Ousip Analyzer Ma,miai/ pages 8-8# B-9* This 

section docuiaents the macro DC8DF$. This macro is 

used to declare the DCS syabolic offsets. 

RSX-llM System Logic Manual/ Volume 1/ pages 3-34 to 8-36. 
This section docaaents the macro DCB,OF$. This macro 
is used to declare the DC8 symbolic offsets. 



B.2. 2 Unit Control Block 



The Unit Control Block (UCB) Is the key device structure 
and is very important to ACP's. There is one UCB for each 

separate device. The UCB provides the characteristics of the 

device, pointers to the other device structures, and Horking 
space for storing I/O related parameters. 

The oca's are variable in length. The follouing locations 
are of concern to ACP's; 

U.CTL Control Flags. This byte contains flags uhich 
control hoM and when the RSX-llM executive Mill 

call the device driver. While ACP's are not 

directly concerned with this process, the setting 
of these bits is important to correct operation, 
particularly if aritlng a UCP. The following bits 
are defined for this bytes 

OC.ALG Alignment bit. If this bit = 0, then byte 
alignment of data buffers is allowed. 
Otherwise, the buffers must be 
word-aligned. This setting is typically a 
function of the device and is not of 
importance to ACP's. 

UC.ATT Attach/Detach notification. If this bit is 
set, the driver is called when $GTPKT 
process an Attach/Detach I/O function. 
However, if the device is marked mountable 
(0¥..MMT=I1 and is mounted (US.MJIT -and 
U3.FQR=0 ), then attaches are never allowed. 
The device will not be notified regardless 
of the state of this bit. 
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-2 ! fJCB Address of O^snex TT; 1 0-0«N 

00 i DCS Address } 0.DC8 

02 I Redirect UC3 Address ! U.RSD 

j 1 

04 I Dnit Status | Control Flags 1 U«CTL O.STS 

j j 

06 I Unit Status I Unit Number I 0-USIT 0.ST2 

10 i Characteristics Iford #1 I U.CMl 

12 I Characteristics Word #2 I O.CW2 

1 J 

14 ! Characteristics Word #3 | 0.CM3 

I J 

16 I Characteristics Word #4 I U-CW4 

20 I sea Address 1 0.SC3 

22 ! TCB of Attached Task 1 D^ATT 

24 1 I D,80F 

I Buffer Address j 

26 \ I 

30 I Byte Count I U.CIT 

j 

32 I ACP TCB Address I U-ACP 

34 I yea Address | U.VC8 
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Macro 


Source Filename: 


OeSDF .MAC 


Macro 


Library Filaname: 


FXEMC .ML8 


vj i ob ai 


0 e f ini t i on F 11 a : 


SXEDf ,MAC 


Object 


Library Filanama:. 


SXELIB.OLB 




Figure' a -5 






IICB 
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UC.KIL Unconditional Cancel I/O notification. If 
this bit is set/, the dri¥er la., called 
whenever e cancel I/O request is issued/ 
even if the aevice- is not busY« ?cr AGP 
enaoied devices (yS-i4NT=0)/ the I/O queue 
is never flushed, iloaavar/ the driver aiil 
be called if the unit is busy and aill 
alaays be called if this bit is set. This 
feature can be used during I/O rundown {see 
section 4.5). 

UC.QDS Queue bypass bit. If this bit is set, the 
QIQ processor calls the driver without 
queueing the request- jilhen writing an UCP/ 
this bit is set. This allows the driver to 
process the I/O request and send it to the 
AGP/ bypassing the normal executive 
processing- 

OC.PMF Unconditional call on power recovery. If 
this bit is set/ the device driver will be 
always be called when power recovers and 
also whenever the driver is loaded or the 
system booted. If the driver is involved 
with enabling its AGP/ this bit provides 
one mechanism for calling the driver so It 
can enable the AGP. 



UC.MPR MPR device. This bit is set if the device 
is an MPR davica- It determines how U-80F 
will be setup. The setting of this bit is 
a function of tne device and is not 
important to the AGP writer. 

UC.LGH Suffer size mask- These bits determine the 
required buffer size. They are a function 
of the device and are not iaportaat to the 
AGP writer. 



0-STS Unit status- This byte contains various flags 
related to the status of the device unit- The 
following bits are defined: 

'JS.BSy Unit . busy. This bit is .sat by $GT.?KT 
■whenever a packet is dequeued for a device 
arivec- and cie-are<i by .$IODOM/.$IOILT when 
the pac.ka£ is finished. The bit is not 
affactad by aueueing a packet to an AGP and 
is not of ' concern to t.he AC? wri'ter. 

US.Ml^T Device mounted. The bit is cleared if an 
AGP is enabled for the unit. It is the 
responsibility of the AGP enabling process 
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to clear this bit. The ACP itself usually 
sets- the bit yften- it- finally' ex-its (see 
liS. MOM beioa). 

US, FOR Foreign ACP. This bit is- supposed to be 
set if non-Digital ACP's are enabled for a 
device. However, the interpretation of 
this bit by the executive is currently is a 
state of flux. For both uCP's and UCP's, 
this bit should be I'Oft off. 

OS. MOM Device laarlced for diseaount. This bit is 
set by the disabling process when the AC? 
is initially requested to be disabled. 
ACP's cannot exit until all processes are 
terminated- Mormally^ the ACP examines 
this fait and its o«n internal state. Mhen 
this bit is set and the ACP is idle, it may 
then exit properly. 

O.cai Device characteristics aord fl. This Hord contains 
bit flags defining the type of device. This aord 
and other three device characteristics are returned 
by a GLUH$ directive. In particular, this word is 
used by FCS to determine the type of I/O request to 
issue to the assigned device. The following bits 
are defined for this aord- 

DV.REC Record-oriented device 

0¥.CCL Carriage-control device 

Oy.TTY Terminal device 

OV.OIR Directory device 

DV.SDI Single directory device 

DV.SQD Sequential device 

Otf.MXD Mixed Massbus device 

DV.UMD Device supports user-mode diagnostics 

DY.SML Device is softaare write-locked 

DV-PSE Pseudo device 

DV-COM Device mountable as DSCNET Phase I device 
DV-Fll Device mountable as Files-11 device 
oy.MNT Device mountable 

These bits should be set carefully. They are 
examined in many placas and the interpretation is 
not always consisteat- FCS considers any device 
with Of. R£C off to be a block- l/Q. device, 
supporting the Fties-11 QIO's- It' also tests 
DV.OIR to see if directory operations are allowed. 
The MOU/OMO tasks also examine the bits to 
determine the proper steps to be taken. In general 
DV.MMT should always be set for devices your ACp 
will service. The remainder of the bits should be 
setup according to the nature of the ACP and its 
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dav ic3S. 

y.ACF ACP TCB address, Tliis «ord is an UC3 extension 
used for aoun table devices. It is set uiien the - AC? 
is snablad to contain tiie TCB address of the ACP. 

O.VCB yes address. This uord is an OCB extension used 
for mountable devices. It is set uiien the ACP is 
enabled to contain the address of the yCB for the 
unit. 



References: 



RSX-llM Guide to Mriting a Device Driver^ pages 4-19 to 
4-26. This is a location by location description of 
the UC8. It is oriented to device drivers, 

HSX-llM Guide to Writing a Device Driver/ pages C-21 to 
C-23, This section docuaents the fflacro 0C8DF$, 

8SX-11M Crash Dump Analyzer Manual/ pages 8-18 to B-25. 
This section documents the macro DCBDF$. 

8SX-11M Systea Logic Manual, Voiuae 1, pages 8-51 to 3-56. 
This section documents the macro UC8DF$, This macro 
is used to declare the 0C3 symbolic offsets and bit 
masks. 



3,2.3 Status Control Block 



The status control block is used to control access to the 
hardware controller. ACP's are usually not concerned with this 
data structure unless they are closely coupled to the device 
driver. 

References ; 



RSX-ilM Guide to Writing a Device Driver/ pages 4-15 to 
4-19. This is a location by location description of 
the 3CH. It is oriented to device drivers. 



SSX-IIM Guiae- to Writing a Device Driver/ pages C-17/ C-18, 
rhis section docuaeats the macro SCBO?$. This macro 
is used to cleciare tne 3C3 symooiic offsets. 

SSX-llM Crash Dump Analyzer Manual/ pages 3-10/ 8-11. This 
section documents the macro SC8DF$, This macro is 
used to declare tna 3CB symbolic offsets. 
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\ ============================:™= I 

00 1 Control l*ar J 3*LHD 

I I/O 1 

02 I Queue Listhead I 

i j 

04 1 /ector/4 1 Priority | S-PRI S-¥CT 

J 1 

06 I Initial TMO } Current TMO | S.CTM S.ITM 

10 1 Status ! Index I S.CON S.ST3 

I 

12 I CSR Address I S.CSR 

I 1 

14 1 Current I/O Packet Address i S.PKT 

I 1 

16 ! I S.FRK 

20 I I 

i Fork Block 1 

22 I I 

i 1 

24 I 1 

26 1 J 

Symbol Definition Macro: SCBDF$ 

Macro Source Filenaiae: SCBDF *MAG 
Macro Library Filenaffla: EXEMC .MLB 
Global Definition File; SXEDF -MAC 
Object Library Filenaae: EXELIB-OLB 



Figure B-6 
sea 
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RSA-llM System Logic 'Manual./ V'oiuae 1/ pages 8-44 to 8-46* 
This . section documents, the siacro SC.3DfS« This macro 
is used to declare the SC3 sy.mao.iic offsets. 



B.3 AC? CQMMOU DATA 3TR0CTUR.E3 



Two type of data structures are common to all ACP'ss 
window blocks and volume control blocks. Window blocks are used 
to map a logical process to a specific logical unit. Volume 
control blocks are used to hold information about each separate 
entity the ACP processes. While all ACP's use these structures/ 
their content is ACP dependent. 
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Figure 8-7 
VCB 



8-3.1 Volume Control Slock 



Typically/ each mounted unit serviced by an ACP has a 
volume control block. This is the data structure in which the 
ACP should hold information raiating to each mounted unit. As 
such/ ¥C8's are ACP dependent except for the first word. 



The first word Is called the transaction count- This 
counter is used by the AC? to determine whether It is idle or 
not. For DCP's/ the counter is incremented whenever a I/O 
request is queued to the OCP and decraiaent by the DCP when the 
request is finished*. It is -also incremented by the OCP when a 
process is a, 3 ta.biished and decra.mantad w-hen the or. oca ss. is 
tarminatad. The OCP cannot exit ynix t.he counter reac-hes zero- 



The executive does not touch the transaction count for 
UCP's/ nowevec/ it is recommended that the CCP's use the 
transaction count for the same purpose- It is important that an 
ACP never exit with I/O requests still outstanding in its queue - 
These requests will never be terminated/ leaving the issueing 
task stuck in I/O rundown. 
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Figura B-3 
MIMDOM BLOCK 



8.3.2 Mindow Block 



One of the roost useful features of an ACP is the ability to 
establish an I/O process and tie various I/O request to the 
process. In the case of Flles-ll, this takes the forn of 
opening a file, reading and writing blocks and closing the file. 
For DECNST, logical links are created, data transmitted and 
received, and the link closed. 

The Mindou block is the data structure used for such 
processes. It ties the task's LOH to a particular process. 
However, the format of window blocks and how they are allocated 
and deallocated is ACP dependent. 

The window block address is stored in the second word of 
the LUT entry. The address of this word is passed to the ACP in 
the I/O packet. Mhile typically the window Is allocated fro® 
the executive's pool but this need not be true. The executive 
never references window address, therefore, the window may corae 
the the ACP's address space. However, if access to the window 
is needed in processing the I/Q request, the window will have to 
coffla froo the pool. 



8.4 OTHER DATA STRUCTORSS 



This is a broad category of 
privileged task and have- the 
create -any structure nscassary. 
roentxoned. 



every thing else. ACP's are 
ability to examine, aodify, and 
Soros of the most iaportant are 
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a«4.1 Clock aueiue Entry 



iCP's often have a raqsiirasent for keeping internal timers 
particularly for event timeouts- One aac^hanisa for doing thi 
is to use the mark time and event flag directives like a norma 
task* An alternative mechanism is to issue an internal timer 
request. When this request expires, an executive or device 
driver routine is called. The foraat of such a request is shown 
below. 



Mhen the internal timer mechanism is used, a linkage must 
be made between the kernel code servicing the timer event and 
the ACP. One method for doing this is for the device driver to 
issue a special I/O request to the ACP that signifies timer 
service. 



1==============^================ I 

00 I Clock Queue Link I C.L^K 

02 I EFl (Unused) I Request Type | C.RQT C.EFN 

j j 

04 1 TCfl or System Subroutine ID | C.TCB 

I 1 

06 1 i C.TIM 

j Absolute Time Entry Due \ 

10 ! } 

j j 

12 I Subroutine Address I C.SU8 

I j 

14 i Relocation Base 1 C.AR5 

j j 

16 I Unused I 

{ ============================== 1 

20 C.LGTH 



Symbol Definition Macro: 
^acro Source Filename: 
Macro Library Filename: 
Global Definition File: 
Object Library Filenames 



CLKDFS 
CLK9F .MAC 
EXEMC .MLB 
EXE.DF .MIC 
EXEL13-0L3 



igura 



21TRY 
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The advantage of the internal method is related to the AGP 
stop aaechanisia... ahen idie^. ACRE'S- can be siaapped out and: not 
brougat back until there is soiae thing to do. Hoaever^ if the 
AC.P maintains a constant tiaer, it Hill be saapped in 
continue! y,/ even if idle. If the tiaier is moved to a driver/ 
the driver can have the intaliigance to notify the AGP only aha n 
an actual timer event processing is needed. 

Rafarances : 

RSX-llM Guide to Writing a Device Driver/ pages C-3/ C-4. 

This section documents the macro CLS0F$. This macro 
is used to declare the clock gueue entry symbolic 

offsets and bit masks. 

RSX-llM Crash Dump Analyzer Manual, pages 8-26, 8-27. This 
section documents the macro CLKOF$. This macro is 
used to declare the clock queue entry symbolic offsets 
and bit masks. 

RSX-llM System Logic Manual, Volume 1, pages 8-31, 8-32. 

This section documents the macro CLKDF$. This macro 
is used to declare the clock queue entry symbolic 

offsets and bit masks. 



3-4.2 Partition Control Block 



The Partition Control Block (PCS) defines how memory is 
allocated. It also provides the linkage between the TC3 and the 
task header. Typically, ACP's are unconcerned with PCB's, 
however, special applications may involve their usage. 

References; 



RSX-llM Guide to Writing a Device Driver, pages C-14, C-15. 
This section documents the macro PCBDF$- This macro 
is used to declare the PCS symbolic offsets and bit 
a asks - 

RSX-1114 Crash Oump Analyzer Manual, pages 3-12 to 8-15. 
This section documan ts the- macro PC30F3. This macro, 
is used • to dscl.are the PCS symbolic of:fsets and bit 
masks. 

RSX-llM System Logic Manual, Volume 1, pages 8-41 to 8-43. 
This section documents the macro PCBOF$. This macro 
is used to declare the PCB symbolic offsets and bit 
masks- 
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I =============================^= I 

00 I Link to Next PCB J P.LMK 

I j 

02 J I/O Count 1 Priority } P.PSI P.IGC 

I— 1 

04 1 I P.MAM 

|— Partition Marne — j 

06 i i 

10 I Pointer to Next Subpartition j P.SOB 

j 1 

12 I Pointer to Main Partition \ P.MAIN 

I 1 

14 I Starting Address Bias 1 F-REL 

I } 

16 1 Size of Partition I P.3LKS 

I _l 

20 I I P.WAIT 

I Partition Mait Queue — •! 

22 I I 

I 1 

24 i Partition S«ap Size I P.S1S2 

j- j 

26 1 Partition Susy Flags | P.BUS? 

30 1 TCB Address of Qunlng Task I P.QWM 

1-^ j 

32 i Partition Status Flags I P.STAT 

34 1 Address of Task Header 1 P.HDR 

j 1 

36 I Protection Mord I P.PSO 

I j 

40 i I P.ATT 

I Attacnaent Descriptors — I 

42 i I 

I =============================== j 
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a,4«3 Task Control Slock 



Tha Task Control aiock is the Rciaary data structiire for a 
task* ACP's are tasks and have a TC3* Besides the normal 
treatment/ tha ICP's TCB receives the following special 
treataant. 

1« The address of the ACP's TCB is stored in the OCS for 
each enabled device* The address is nsea to dateraine 
to which task to queue the I/O request. 

2. The I/O packets are queued to the ACP through the 
receive queue listhead (T.RCVL) and deallocated by the 
ACP by removing an entry from this queue. 

3. ACP's are marked by a special bit in the third status 
word (T.ST3). This bit (T3-ACP) is used to prevent 
tasks from sending messages to the ACP. This is 
necessary to prevent confusion resulting from multiple 
usage of the receive queue. The bit is set by the task 
builder /AC switch. 

4. For certain Digital ACP's (FllACP, HTAACP), the second 
event flag word <T.SFLG+2) is used as a mounted volume 
counter and therefore event flags 16-31(10) are not 
used. However^ this restriction applies only if 
desired. 



References j 



RSX-llM Guide to Writing a Device Driver/ pages C-19/ C-20. 
This section documents the macro TCB0F$. This macro 
is used to declare the TC8 symbolic offsets and bit 
masks. 

RSX-llM Crash Dump Analyzer Manual/ pages 8-15 to 8-17. 
This section documents the macro TCBDF$- This macro 
is used to declare the TCB symbolic offsets and bit 
masks. 

RSX-11'4 System Logic Manual, Volume 1, pages 8-47 to 8-49. 
This section documents tae macro TC30F$. This macro, 
is used to declare the TCB symbolic off. sets and bit 
siasks.> 
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1 
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I 
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1 — 

I 



{Jtiilty LinK Mord 1 T,LdK 

1 

I/Q Count I Priority J T.PRI T«I0C 

Chackpoint PCB j. T.CPC8 

- j 

I T.NAM 

- Task Harae 1 

J 

— I 

I T.RCYL 

- Receive Queue Listhead 1 

I 

1 

1 T.A3TL 

- AST Queue Listhead 1 

I 

} 

I T-SFLG 

- Local Event Flags 1 

1 

1 

Tl; oca Address i T.UC8 

J 

Task List Thread Mord 1 T.TCBL 

1 

Status Mord (Blocking Bits) 1 T-STAT 

Status Word (State Bits) ! T*ST2 

1 

Status Mord (Attribute Bits) 1 T.ST3 

I Def. Priority 1 T.DPRI T.L3S 

L8M of Load Image 1 

OCB Address of Load Device 1 T-LDV 

j 

PCB Address I T.PCB 

1 

Maxifflum Task Size i T-MXS2 

5 

Pointer to i^axt Active tC3 I-. T-ACTL 
Specified AST Listhead j T»31ST 



Figure 3-11 
TCB 
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I 

bo I I T:.1TT 

i Attaclix^ent Llsthead -—I 

50 I j 

I I 

62 I Task Image Partition Offset } T.QFF 

64 I SFN Count j Unused I T.SRCT 

I j 

66 ! I T.RRFL 

j Receive oy Ref Listhead 1 

70 I 1 

j J 

72 I I T.OCBH 

1 Offspring Control List — i 

74 1 I 

76 i Offspring Count | T-RDCT 

I =====================:========== 1 

100 T.LGTH 

Symbol Definition Macro: TCSOF$ 

Macro Source Filename: TCBDF .MAC 
Macro Library Filename: SXEMC .MLS 
Global Definition File: EXEDF .MAC 
Object Library Filename: EXELI8.0L8 



Figure 8-11 
TC8 
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8,4,4 Task- Header 



The task, header contains the context of the tas.k. The aost 
important thing to raflieabar about tasic Headers is that they are 
destroyed yhen a task is checkpointed and recreated when it is 
syapped in. Therefore, ACP's cannot store the address of the 
header (or the LOT table) for later use. 

References: 

HSX-llM Guide to Mriting a Device Driver, pages C-9, C-10. 

These sections docuaent the macro HDRDF$. This macro 
is used to declare the task header symbolic offsets. 

R3X-11M Crash Dump Analyzer Manual, pages 8-4 to B-6. 
These sections docuaent the macro HDSOF$. This macro 
is used to declare the task header symbolic offsets. 

RSX-llM System Logic Manual, Volume 1, pages 8-49, 8-50. 

These sections document the macro HDRDF$. This macro 
is used to declare the task header symbolic offsets. 
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I ============:===:====.============ i 

00 1 Cur=rant stack Pointer l a.CS? 

02 1 . Header Length I H.HDLa 

} — 1 

04 ! 1 H.SFL« 

I Stfent Flag Masks i 

06 1 I 



10 1 Currant Task UIC i H.COIG 



12 ! Default Task OIC ! H-DOIC 



14 I Initial PS J B.IPS 

16 1 Initial PC I H.IPC 

I _j 

20 \ Initial SP I H.I3P 

j 1 

22 1 QDT SST Vector Address f H,OD¥A 

24 i QDT SST Vector Length I fl.QDVL 

26 1 Task SST Vector Address 1 fl.TKVA 

30 1 Task SST Vector Length I H.TXVL 

I , 



32 1 Powerfail AST Block Address \ H.PFVA 



34 I FPP AST Block Address i H.FPVA 

i 1 

36 I Receive AST Slock Address I H.RCVA 

j 

40 1 Event Flag Save Address 1 H.SF3V 

I — .j 

42 I FPP/EAE Save Address I fl.FPSA 

44 i Pointer to Sumbar Windows 1 H.MMO 

} 1 

46 I OSM 1 H.DSM 

I 1 

50 1 FCS Impure Pointer I H.FCS 



52 ! Fortran Isapura Pointer I H.FQST 



I Over lay Impur e Po iatec I H.OVLY 



o6 ] Work Area Extension Pointer \ H.VEXT 



Figure 8-12 
TASS HEADER 
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50 I Mailbox LDl j SMapping Pri* I H.SPRI 



5 

52' I Rec/Ref AST Block Address j H.HR¥A' 

I I 

64 / / 

/ Reserved / 

/ / 

I I 

72 j pointer to Guard Mord 1 H»GARD 

I J 

74 1 Sufflber of LUM's I H.L8M 

J J 

76 / / 

/ LUT fable / 

/ / 



Symbol Definition Macro: 
Macro Source Filename: 
Macro Library Filename: 
Global Definition File: 
Object Library Filename: 



HDRDF$ 

HD RDF .MAC 
EX EMC .MLB 
EXEDF .MAC 
EXELIB.QLB 



Figure B-12 
TASK aSAOER 
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fC3-ll: MODULES 



The File Control Services are a set of routines uhich are 
linked to a task to perfor® various I/O services. The routines 
are typically called via Macros. The documentation for FCS is 
found in the IAS/RSX-11 I/O Operation Reference Manual. 

There are two levels of FCS routines. The upper level 
routines are called directly by the user's task or via the FCS 
macros. These routines are named '.XXXXX'. The lower level 
routines are Intended for FCS's own use and are not expected to 
be called directly by the user. These routines are named 
'..XXXX'. This appendix describes each FCS module^ its entries, 
and their calling parameters and function. The appendix also 
discusses the FCS data structures and some basic internal 
concepts. 



C.l FCS CONDITIONALS 



Each FCS module is assembled with the prefix file 
FCSPRS.MAC. The file establishes various symbolic definitions 
and common macros and defines the assembly control flags. FCS 
is very heavily conditionally assembled. The symbols used and 
their default RSX-llM values are as follows; 

R$$ANI ANSI magtape support. This variable is set to zero 
for no support and to one if ANSI magtape support is 
desired. The default for RSX-llM is zero unless the 

ANSI prafix Ilia,. INSPRE-MAC, is-. used far assembly.. 

R$$3SF 3.ig buffer support, thi.3 feature is used for I/O 
dev-icas that support .blocx sizes greater then- 512 
bytes. The variable is set to zero for no support 
and to one if support is desired. The default for 
RSX-llM is zero unless the ANSI prefix file, 
AN3PRE.MAC, is used for assembly. 

RSSDPB QIO DPB format. This variable is set to zero for 
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old style QiG^'s and to one for the nea QIQ OPB 
format, Xt this, time^ ail systems (including. 
RSX~ilM) use the nea focaat. 

R$$SI3 Extended Instruction Set (SIS) support. This 
variabia is set to zero if no SIS instructions 
should be used by FCS and to one if SIS instructions 
are ailoaed, RSX-llM alaays sets this variable to 
zero. 



R$$EL? Extsned parsing support. This variable is set if 
extended parsing support for VAX/VMS systaras is 
desired. RSX-llM always sets this variable to zero. 

R$$LCL Force local definition of symbols. This variable is 
set to zero if global definitions for FCS variable 
should be used and to one if local definitions 
should be declared in FCSPRE.MAC. RSX-llM sets this 
variable to one. 

R$$MPL RSX-llM PLUS support. This variable is set to one 
if FCS should be assembled for an RSX-llM PLUS 
system. RSX-llM always sets this variable to zero. 

R$$MUL Multiple buffering support. This variable is set to 
zero if FCS supports only one I/Q block buffer and 
non-zero if multiple I/O buffers are supported. The 
symbol R$$MBF is eguated to this symbol. RSX-llM 
always sets this variable to zero. 

R$$MAM Samed directory support. This variable is set one 
or two for named directory support. This is a 
feature of the 3CS-11 version of FCS- RSX-llM 
always sets this variable to zero- 

R$$OPF Type of open- This variable is used to control the 
type of assembly desired for the module OPES. If 
set to zero^ the normal OPEN routine is assembled. 
Otherwise/ a value of one (OPFNB.MAC) assembles the 
open by FMB and a value of two (QPFIO-MAC) assembles 
the open by FID module- This variable is not set in 
FCSPRE.MAC. 



O (f O Q T 



is.semb.le for SYS.LIB or ra3ida,nt iib.rary.- Thi.3 
variable is set to zero if FCS should, be assembled 
■for placamenx in 3¥S.LIB..0La or one if a resident 
library should be- bui.lt from FCS. RSS-llM always 
sets thi.3 variable to one. This causes FCS to 
assaabiad using the PSSCT S$R£SL. 



R$$SCS 3CS-11 support. This variable is set to one if FCS 
should be assembled for the SCS-11 operating system. 
RSX-llM always sets the variable to zero- 
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R$$oSQ Type of file I/O-. Th.i3 variab.ia is used to control 
the type of asseaibly desired for the GET and PUT 
iaoduies. If set to zero^r the laodulas support both 
sequential and randoo I/O. If sat to one (POTSQ#' 
U iti.i J / t-h s modules are restricted to sequential 
I/O. This variable is not set in FCSPRE.HAC. 

R$$3PL Automatic spooling support. This variable is set to 
zero if no automatic spooling support is desired and 
to one If it is supported. RSX-llM always sets this 
variable to zero, support of automatic spooling 
requires the IAS spooling aechanism- 

R$$tfMS VAX/YMS support. This variable is set to one if PCS 
should be assembled for VAX/VMS operating system. 
RSX-llM alaays sets this variable to zero. 

RSX-llM support. This variable is set to zero if 
IAS support is desired and to one if RSX-llM support 
is to be generated. Maturally/^ RSX-llM sets this 
variable to one. 

Figure C-1 summarizes the default conditional switch 
settings for the five operating systems supported by FCS. In 
general, RSX-llM sets the FCS conditional symbols to assemble 
the simplest version of FCS. It is unclear what will happen if 
some of the more useful features (R$$EIS, R$$SPL, R$$MUL) are 
turned on and used in an RSX-llM system. 
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FCS DEFAULT CQND ITIOSALS 
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C.2 FCS DATA ST ROC TORES 
<To be arittan> 

C-2.1 File Descriptor Sloclc 
<To be «ritten> 

C.2. 2 Filename Block 
<To be aritten> 

C.2.3 Dataset Descriptor 
<To be aritten> 

C.2.4 $$FSH1 Region 
<To be Mritten> 

C.2.5 $$FSR2 Region 
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5 =============================== I 

00 j Record . A ttr». I Record Type | F.HfYP F„RATT 

02 j Record 3 iza 1 F.RSI2 

04 I 1 F-.HI3K 

I Highest V3M Allocated i 

06 1 I 

10 1 ! F,£FBK 

1 EOF Slock flufflber 1 

12 J i 

j I 

14 I First Free 8yte in EOF Block I F.FFSY 

16 i Device Chars ] Record Access 1 F.RACC F-RCfL 

— j 

20 i Block I/O Buffer Descriptor 1 F.8KDS/F.4MRBD 
1-^ — or — i 

22 I User-record Buffer Descriptor I 

I 1 

24 I Block I/O Status & AST Addr- 1 F.BKST/F.NRBD 

1 or i 

26 I Next-record Buffer Descriptor I 



V 30 I Buffer Size/Hext Record Addr. I F.OVBS/F.SREC 

j 1 

32 1 Snd-of-block Value I F.E088 

j 1 

34 I Create Quantity & Statistics I F.CNTG/F.RCNM 

1 or ■ — i 

36 1 Record Number 1 F.STBK 

I 

40 I Extend Quantity I F.ALOC 

I I 

42 I File Access | LUH Mumber I F.LON F.FACC 

, «j 

44 i Dataset Descriptor Pointer I F.DSPT 

I 1 

46 I Default Filenaffle Block Addr. I F.DFM8 

I 1 

50 1 aookkeeping I EFH I F-BKSF F.BKPl 

J 1 

:b2 I Error «ord I F.SSR 

1 



Figure C-2 
FDB 
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j 1 . 

54: \ Buffer Count i Mul- Suf. :i 0 . 1 E.MBCT E.I48C1 

} I 

bo j Res-eryad 1 Mui. Buf.. Sit i E.MSFG F.BGBC 

60 j Device Buffer Size } ?«783Z 

, — I 

52 ! Block Buffer Size I F.BBS2 

64 i } F.BKVB/F.V8M 

i — - ¥8N M umber 1 

66 I I 

i 

70 I Block Suffer Descriptor 1 F.8D8 
72 I Spooling Device I F.SPDV 

74 i Reserved 1 Spooling Unit I F.SP03 F.CHR 

—I 

76 I Control Bits I F.ACTL 

100 i Sequence Muaber i F.SEQM 

102 Start of FMB F.FNB 

/ 



Symbol Definition Macro: FCSST$y F00FF$ 
Macro Source Filename: FCSMAC-MAC 
Macro Library Filename: RSXMAC.SML 
Global Definition File: FCSGBL-MAC 
Object Library Filename: S¥SLI3,QLB 

Figure C-2 
FOB 
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i =============================== 1 

00 |. I N.FID. 

02 ] ?iie-ID I 

04 1 I 

j — I 

06 i I N.FMAM 

10 1 Filanaflie I 

j 1 

12 1 1 

I 1 

14 I File Type I N.FTYP 

I 1 

16 1 Version I N.FVER 

j J 

20 I Status I N.STAT 

I J 

22 I Next File I N-NEXT 

J 1 

24 I I N.DID 

j j 

26 I Directory ID I 

I 1 

30 I I 

I 

32 I Device Name I N.OVMM 

I , 

34 1 Unit Number J M.UNIT 

j =============================== } 

Symbol Definition Macro: FCS8T$, S80FFS 
Macro Source FilenaiBe: FCSMAC.MAC 
Macro Library Filename: RSXMAC.SML 
Global Definition File: FCSGBL.MAC 
Object Library Filename: SYSLI8.QL8 



Figure C-3 
FIB 
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08 
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Device String Length 


1 a.OEVO 


Device String Address 


1 


Directory String Length 


! N.DIRD 


1 

Directory String Address I 

1 


Filename String Length 


~ 1 
1 
1 


Filename String Address 


1 

\ 

= 1 



Symbol Definition Macro: FDSOF$ 
Macro Source Filenaae: FCSMAC-MAC 
Macro Library Filename: RSXMAC.3ML 
Global Definition File: FCSGBL*MAC 
Object Library Filename: 3YSLIB.0LS 



Figure C-4 
DATASET DESCRIPTOR 
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00 

02 

04 

06 

10 

12 

14 

16 



I „ I 

I I/O Status Block 1 

i I 

1^ j 

1 i 

I Virtual Block Mumber 1 

1 1 

j j 

i Address of Mext Buffer i 

j , 

1 Buffer Status 1 Empty I 

I— .J 

I Empty 1 

/ Start of I/O Buffer / 

/ . / 

/ . / 

/ . / 



B-VBN 



B.NXBD 



S.8FHD 



B.BF3T 



SyjBOol Definition Macroi 
Macro Source Fllenaaei 
Macro Library Filenaaei 
Global Definition File: 
Object Library Filename: 



aDQFF$ 

FCSMAC.MAC 

RSXMAC.SML 

FCSG8L.MAC 

SYSLI8.0L3 



FIGURE C-5 
SSFSRl 
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I =============================== I 

00 J 1 

I Allocatioa Listhead -—1 

02 I I 

04 I First Address in FSRl I A-BFSR 

j 

06 I Last Address in FSRl i A.EFSR 



10 1 File OHner OIC I A-OiOI 

j 1 

12 I Default File Protection i A.FIPR 

14 / / A.DPB 

/ Scratcls Area and QIO DPfi / 

/ / 

j 1 

44 I I A.IOST 

I Scratch I/O Status Area i 

46 f I 

I i 

50 / / A.DFOR 

/ Default Directory Information / 

/ / 

j 1 

100 1 Default Buffer Count I A.DF8C 

j 

102 I Default Task OIC I A.DFOI 

} =============================== I 

Syiabol Definition Macro: FSROF$ 

Macro Source Filename: FCSMAC«MAC 
Macro Library Fiienaae: SSXMiC-SML 
Global Definition Files FCSGSL-MAC 
Object Library Filename: 3YSLIB-0L3 

PI GuRS C-6 
SSF3R2 
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C,3 PCS . Ic^TSSMaLS 



<Tq be written> 



C,4 PCS MODOLES 



The reiaainder of this appendix covers each PCS source 
module. For each module/ the calling label and inputs and 
outputs are detailed 



C.4.1 AMSPAD 



This routine pads the rest of the buffer for magtape ANSI 
"D” format. It is only generated If magtape support (R$$ANI) is 
selected. 



Entry: ..AISP 

Input: RO = FD8 address 

F.NREC(RO) = Starting address in buffer to pad 
F.EOaS(RO) = Byte address beyond end of buffer 

Output: C = 0/ If buffer padded 

= 1/ If buffer not padded 

R0-R4 preserved/ R5 destroyed 

Conditionals: R$$AMI 



C.4.2 ASCPPM 



This routine transiatas an OIG string in the form of 
"C200,210.1« to the binary equivalent. Both the group: and owner 
numDers are assuiaed to. be octal unlass fallowed by a period. In 
his- case/ the numbers, are translated as decimal. The output is 
toted In ".BYTE own at/ group*** form. 



Entry: .ASCPP 



Input: R2 = Address of UIC string descriptor 
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R3 = Addrsss to return the binary GIC 

0(R2) = Size of OIC string 
2(R2) = Adaress of UIC string 

Output: C = 0/ String conyerted and value stored 
= 1/ UIC string syntax error 

All registers preservad' 

Conditionals; ?lone 



C.4.3 ASCR50 

This routine converts an ASCII string to RA050 and stores 
in the specified locationfs). 

Entry; •.SGR5 

Input; R2 = Address of ASCII string 
R3 = Size of ASCII string 

R4 = Starting address to store RAD50 string 

The storage area must be previously zeroed. 

Output; C = 0/ Conversion coaplete 

= Ir Conversion failed, nonalphanuojeric character 

R4 = Address of last word uritten in RAD50 

R0,R1 preserved,’ R2,R3^S5 destroyed 

Conditionals; R$$£IS 



C.4.4 ASSLUM 



This routine assigns the lun . in F.LUM of- the FD3 to tna 
device- specified by- the- filename block. If no device is 
specifiaa, the pcaviously assigned devica is- used. If no device 
was assigned,, the defauit devica (SY:) is assigned. 

Once the device is assigned/ the device characteristics are 
stored in the FD8. Specifically, the low byte of the the device 
characteristics (U. CWl) is stored in F.RCTL and the device 
buffer size (0.CM4) is stored in F.VBSZ and F.SBFS. Also, the 
true device name and unit are stored In the filename block. 
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CtXiti'c * # A is-L* U M ^ • AL u M 

Input! fiO = FOB address 
31 = FrIB address 

3l«USIT<ai) = Device unit nunider 
S.D¥HM(H1) = Device name or 0 if none 

Output! G = 0/ Assign succassfui 
= Bad device naiae 

F.RCTL(ao) = Device characteristics 
F.?BSZ(RO) = Device block size 
F«88SZ(R0) = Device block size 

If entry at -ASLUM^ all registers preserved 

If entry at ..ALOM^ R0,R1 preserved^ R2-R5 
destroyed 

Conditionals: R $ $ AMI , R $$ S PL , R$ $ 1 1 M 



C,4.5 B08REC 



This routine sets up the block buffer header and the FD8 
for the next virtual block I/O, 



Entry: ..80RC 



Input: RO = FD8 address 

R1 = Suffer descriptor address 



Output: B.vaM(Rl) 
B.BBFS(Rl) 
F.HREC(RO) 
F,EQBB(R0) 



Set to F.VBM(RO) 

Set to F.BSFSCRO) 

Set to start of I/O buffer 
Sat to end of I/O buffer 



R0,R2-R5 preserved^ R1 destroyed 



Ainditionais: 



C,4.o 8IG3UF 



This module contains routines used for large buffer 
support. This support is not enabled for RSX-llM (RS$88F>0), 
IMiMBB checks for a specified V8N in the block buffer. RSTEQF 
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correctly processes SOF's for large buffer I/O., 
C.4.7 3K3G 



This routine sets up the registers for block 1/0/ using the 
block buffer definition in the FOB, 

Entry: ..BKRG 

Input; RO = FOB address 

F«BD8(R0) = Buffer descriptor address 

Output: Rl = Address of I/O buffer 
R2 = Buffer size (F.8BFS) 

S3 - Carriage control/ always set to zero 

R0/R4/85 preserved 

Conditionals; Mone 



C.4.8 CKALOC 



This module contains routines to allocate blocks to a file* 
The routines are designed for internal FCS usage. 

The ..ALOC and --ALC1 routines are used to allocate blocks 
if necessary. The desired allocation is compared to the current 
allocation and more blocks are allocated if necessary. 



Entry; ..ALOC 

Input; RO = FOB address 

F.EFBK(RO) specifies block to allocate to. 

i!* n tr y ; ' * . 1 

Input; RO = FOB aadress 

ai = High 73h' to allocate to 
R2 = Low ¥Sh to al locate to 



; C = 0/ Slocks allocated/ F.HIBS(RO) updated 
= 1/ Allocation failed/ F. ERR(RO) contains 
error code 



Output 
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All rsglstars pca3ar.¥e-d^ 

The .«S1TD and --EIT1 roatines are used to extend the file. 
.*£XTO computes the extend size, using f.ALQC if It is non-zero. 
atherHi-se it subtracts the current biocx allocation from the 
contents of R1,R2 and uses the resulting value. ..EXTl actually 
issues the extend QIQ request. 



Entry: 


. . S 


XTD 








Input; 


RO 


= FOB 


address 








R1 


= High 


?BH to 


extend 


to 




R2 


= Low 


¥8M to 


extend 


to 



Output; C = 0# Extend successful 
= If Extend failed 

All registers preserved 



Entry: ..EXTl 

Input; RO = FD8 address 

R1 = 0, noncontiguous allocation 
= If contiguous allocation 
R2 = Number of blocks to extend 

Output; C = 0/ Successful extend/ F.HIBK adjusted 
= If Extend failed 

RO preserved/ R1-R5 destroyed 



Conditionals; RSSDPB 



C.4.9 CLOSE 



This module closes an open file/ writing any remaining 
buffers and rewriting the file header with the final record 
attributes. The FOB is reset. 



Ci n 5* r y . u -ui o s 

Input; RO = FDS address 

Output: C = 0/ successful coapletlon 
= If error writing header 

All registers preserved 
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CoMitionaisJ. RSSAfJI/ 



$ 5 a 8F , R$ $ MB F , R S $ SPL 



,10 



COMMON 



This module contains taro coamonly used routines. The 
first, ..FC3X, is used to properly set the carry bit if an error 
code is set in F.ERP... 



Entry: ..FCSX 

Input: RO = FOB address 

Output: C = 0, F.ERR(RO) is positive 
= 1, F.ERR(RO) is LE 0 

All registers preserved 

Conditionals: None 

The second entry, .FATAL, Is used by FCS to declare fatal 
errors. A 8PT instruction is issued. The current version of 
FCS only uses this routine if an aveot flag directive falls. 



C.4.11 CONTRL 



This module is used to issue the iO-APC function. It is 
normally intended for use with aagtapes. 



Entry; .CTRL,.. CTRL 

Input: RO = FDB address 

R1 = Function code 
R2 = Value 

R3 = Parameter list address 



Output : 



C = 0, operation, successful 

= 1, operation failed, F.SRRfRO) = error code 

If .CTRL, ail registers prasarved 

IF ..CTRL, RO preserved, R1-R5 destroyed 



Conditionals: None 
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C,4.12 CaSA'TS 



This ojoduie coatalns the internai ?C3 code for creating a 
netai file on the dislc« If caileti for a record I/O device 
(FD.R£C=1)#- the routine is affectively a no-op* OtherHise/ the 
lO.CRS function is issued* 



Entry: ..CREl 

Input: RO = FDB address 

R1 - FN8 address 

Output: C = 0, fils created 

= 1 , operation failed# F.ERR(RO) = error code 

R0#R1 preserved# R2-R5 destroyed 

Conditionals: R$$A?1I 



C*4.13 DEL 



This fflodule contains the internal FCS delete code. The 
file is removed from the directory and marked for delete. The 
FN8 is assumed to contain the filename and file-ID. 



Entry: ..DELI 

Input: RO = FD8 address 

R1 = FMB address 

Output: C = 0# delete successful 

= 1# operation failed# F.SRR(RO) set 

R0#R1 preserved# R2-R5 destroyed 

Conditionals: Mone 



C.4.14 OELETS 



This laoduie contains the user interface for deleting a 
file. If the file is opened it is first closed- Then the FMB 
is set up using the dataset descriptor in F-DSPT(RO) and default 
filename block in F.DF13<R0). Finally# the file is deleted. 
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SBtry: .OSLET 

Input: SO = f08 address 

Output: C = 0/ delete successful 

= 1/ operation failed#' F.SRR(RO) set 

All registers preserved 

Conditionals: Mona 



C.d.15 DIDFNO 



This routine begins to find the default task directory* 
The directory number stored in A.BFOI of $$FS82 is converted to 
RAD50 and stored in the filename portion of the FNfl- The 
routine continues at .*010. 



Entry; -.DIDF 

Input; RO = FDB address 
R1 = FNB address 
R2 = FSH2 address 

Output: Binary UIC convartad to RAD50 and stored in F!jB* 
See DIF Mb (next section) for remainder. 
Conditionals; None 



C.4.16 DIFND 



This module continues the directory lookup process. The 
file type is set to DIR (RAD50) and the version to one. A find 
is then performed on the master file directory. If successful^ 
the resulting flle-IO is sat as the directory-ID and the 
remainder of' the FNB is- cleared. 



intry: •.OIDi# .«DXD 

Input; RO = FOB address 
R1 = FN,B address 



M, FMAM(fil) = Directory name 
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0(SP) = Saved a:2 
2(3P) = Saved R3 
4(3P) = Rafc'urn address 

..DIDl saves R2/R3 on stack and fails into .*2ID 

Output: C = Oy directory found/ M.DID setup 
= 1/ no directory/ F.£HS(R0) set 

R0-H3 preserved/ H4/.R5 destroyed 



Conditionals: None 



C.4.17 DIRECT 



This module contains the code used to issue the directory 
prliaitives: enter filename in directory <10. SNA)/ find filename 
in directory (lO.FIA)/ and remove filename from directory 
(lO.RMA). 



Entry: ..EiTR, ..FIND, ..RMOV 

Input: RO = FDB address 

R1 = FN8 address 

Filename block setup for desired operation 

Output: c = 0/ operation successful/ FN8 filled in 
= 1/ operation failed, F.SRR(SO) set 

RO/Rl preserved/ R2-R5 destroyed 

Conditionals: R$$ASI/S$$DP8 



C.4.13 DIRFND 



This module contains the first half of directory string 
pracassimj. The- directory string is turned into a 8A050' string 
and stored as- the aasirad. filsrsame. Processing continues in 
OIFHD at ..DID, The routine is aostly concerned' vith- named 
directories, hoaever, this co-da is disabled for RSX-llM. 



Entry: ..DIRF 



Input 



RO = FDB address 
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21 = ?NS address 

R2 = DirectorY string descrigtor 

Qutgut: C = 0, ogaration succassfuij, diractory-ID setup 
= 1/ operation failedr F*21<fi(:S0) sat 

R0-R3 preserved, R4,R5 destroyed 

C 0 nd i t i o n a 1 s 5 8 $ $ M A M , R $ $ S C S 



G.4,19 DIRMAM 



This routine is only used for SCS-11 systems. It is a part 
of that systems directory processing- 



C.4.20 0LFM8 



This routine is the user interface for deleting a file by 
filename block. The FNB portion of the FOB is assumed to be 
setup with the filename, type, version (must be explicit), 
directory-ID, device, and unit. The file is first closed, 
removed from the directory, and then deleted. 



Entry: .OLFMB 

Input; RO = FD8 address 

Output; C = 0, operation successful 

= 1, operation failed, F.SRR(RO) set 

All registers preserved 

Conditionals; None 



c 



.21 



SLir'ARS 



Tliis routine contains code ahich bypasses the normal F 
filename parsing and uses the facilities provided by t 
operating system. Such support is only turned on if FC3 
assembled for a VAX/yMS system 



sj' a 
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C.4,22 EOF CHIC 



This aodui a contains the EOF checicing cods for rscord I/O* 
The routine ...3EF8 checics to see if the current virtual biocit 
(F.VSS) is at or beyonci the EOF biocJc (F»EFBK)* 



Entry; ..SEF8 

Input; RO = F03 address 

F.VBM<R0) = Current virtual block number 
F.EFBK(aO) = EOF block nuEber 
F«FF8Y(R0) = Last byte in EOF block 

Output; c = 0, if before or at SOf block 
= I, if beyond EOF block 

FD.EF8 in F.BKPICRO) set if at or beyond EOF block 
All registers preserved 

The routines ..EFCK and ..EFCl check to see if the currant 
record position is at or beyond the EOF position. The first 
entry calls ..3EFB to properly setup FD.SFB. ..EFCl assumes 
this bit Is already properly set- If at the EOF block, the 
current record position is compared against the placement of the 
EOF within the block. 



Entry; ..EFCK, ..SfCl 

Input; RO = FDB address 

Output; c = 0, if not at EOF 

= 1, if at EOF, F-ERR(RO) - IE. EOF 

R0,R2-R5 preserved, R1 destroyed 



Conditionals; Mona 



C.4.23 S2TERD 



This module contains the user interface for extending a 
file.. The file may be opened or Closed- 



Entry 



EXTHO 
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Input: RO = FOB address 

R1 = ‘liimdar of blocks to extend file by 
R2 = lype of extend 

0 = Mon-contiguous 

1 = Contiguous 

Output: C = 0/ operation successful/ F.HIBK(RO) adjusted 
= 1/ operation failed/ F.,£RR(R0) set 

All registers preserved 

Conditionals: Mona 



C.4.24 FCSFSR 



This aodule contains the F3R region declarations* $$FSR1 
is declared as a blank psect. The user is expected to expand it 
later. The $$fSR2 region is declared to be of size S.FSR2. 



( C.4.25 FIHIT 



This module contains the PCS initialization code 
Specifically/ the size of the $$FSR1 region is calculated an 
the default UIC is sat fro® the task's UIC. 



Entry: .FIMT/ ..FIMI 

Input: Rl = Address of $$FSR2 region (..FIMI only) 

Output: FSR regions initialized 

Ail registers preserved if entry at .FISIT 

RO/Sl preserved/ R3-R5 destroyed If entry at ..Fill 

Conait Iona Is: ?l one 






This aodule contains the code for inputting a logical 
record froa the devica/fila. The aodule can be asseabled for 
either sequential-only support (R$$3EQ) or randoa/seguential 



Cl « 
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support. Sae the RSX-ll/IlS I/O operations Raferance Manual 
pagas- 3-18 to. 3-23 f or further details on calling saguence an 
r a turn values. 

^*nt,ry2 .GoT^r .Gi^TSu 

Input: RO - FDS address 

Output: c = 0/ record input 

= 1/ operation failed, F.SRR(RG) set 

All registers preserved 

Conditionals; R$$A5'iI,R$$B8F,R$$£IS,R$$RSL,RSSSEQ,H$SllM 



C.4.27 GETDI 



This routine is the second part of the directory look-up 
process. It saves the current context of the FN8 and calls 
either ..PDID or ..DIRF to set the direc tory-ID. The FHB Is 
then restored. 



Entry: ..GTDI 

Input: RO = FD8 address 

R1 = FMB address 

R2 = Directory string descriptor address 

0(SP) = Directory lookup routine {..PDID/.. DIRF) 
2(SP) = Return address 

Output: C = 0, operation successful 

= 1, operation failed, F.SRR(RO) set 

All registers preserved 

Conditionals: R$$SPL 



C.4.23 GSTDID 



This routine gats the default task dlractory-I9 and stores 
it in the specified filenaae block- It sets-up to call -.PDID 
and continues in ..GTDI. 



Cl\ 
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Entry: ,GTOIO 

Input: RO = ?DB address 

31 = FN8 address 

Output: See .«GTDI 

All registers preserved 



Conditionals: RSSELP 



C.4.29 GSTDIR 



This routine look ups the specified directory and stores it 
in directory-ID in the filenaffle block. It sets-up to call 
..DIRF and continues in ..GTDI. 



Entry; .GTDID 

Input: RO = FDB address 

R1 = FN8 address 

R2 = Directory descriptor address 
Output: See ..GTDI 

All registers prasarvad 
Conditionals: R$$£LP 



C.4-30 MKDL 



This module contains the internal routine to mark a file 
for deletion. While the file is deleted by this routine^ the 
directory entry is not removed. 



Entry: - ,.MKDL 

Input: RO = FOB address 

R1 = fSlB address 

Output: C = 0, delate succassiui 

= 1 , delete failed, F.SRR(RO) sat 

RO preserved, R1-R5 destroyed 
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Conditionals: Hone 



C-4.31 MOfREC 



This routine transfers records to and from user buffers. 
It is designed to woric correctly for odd address and odd byte 
counts. 



Entry: ..M¥R1 

Input: RO = FOB address 

R1 = Address of source 

R2 = Address of destination 

R3 = Size of block to move 

Output: R1 = Address of last byte raoved+1 

S2 = Address of last byte stored+1 

R0yR4 preserved, a3,'R4 destroyed 

Conditionals: Hone 



C.4.32 MRKDL 



This module contains the user interface for deleting a file 
Mithout removing the directory entry- 



Sntry: .HRKDL 

Input: RO = FOB address 

Output: C = 0, delete successful 

= 1, delete failed, F.SRR(RO) set 

All registers preserved 

Condi tionais: Mone 



r* h 



33 



GPEM 



This module contains the code for accessing a file. It can 
be assembled into three different versions: normal open 
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(R$$OPF=0)jf open filanaae block; CR$3QPF-1),/ and open by 

f ila-£D ■ (R$$aPF=2), See the- SSX-ll/IAS I/O Operations,- Raf arsnca- 
Manual/ paqes 3-2 to 3-17 for further descriptions o£ the 
calling sequence and outputs. 



Entry: .OPEM/ .OPFSB, .OPFIQ 

Input; RO = FD8 address 

Output: C = 0/ operation successful 

- 1/ operation failed/ F.ERRCRG) set 

All registers preserved 

Conditionals; R$$ANI/R$$a8F,R$$aPB/R$$SIS 

R$$MBF/R$$SAM,R$$QPF/RS$RSL/R$S11M 



C.4.34 PA8DI 



This routine continues the directory parsing process for 
the default directory. If the device and unit agree uith the 
current saved directory-ID's device/ the saved default 
diractory-ID is copied. Otherwise/ the directory-ID is obtained 
and saved for later use. 



Entry: ,,PQI 

Input: RO = FOB address 

R1 = FM8 address 

0<SP) = Directory lookup routine (..DIDF/..DIRF) 
2(SP) = Return address 

Output: C = 0/ operation successful 

= 1/ operation failed/ F.ERR(RO) sat 

All registers preserved 

Conaitionais: R3S3C3 



C.4.35 PASDID 



This routine is a short-hand version of the directory 
lookup process/ specifically designed for default directories. 
It sets up to call ..OIDF for directory processing and continues 




CS-11 MODULES 



PAGE C-27 



in ..PDI* 

Entry: «,?0ID 

Input: RO — FOB address 

R1 = FM8 address 

Output: See .«PDI 

All registers preserved 

Conditionals: Mona 



C.4.36 PARSDI 



This aodule contains the logic for parsing the directory 
specification. 



Entry; .PRSDI, ..PSDI 

Input; RO = FDB address 

R1 = FN8 address 

R2 = DSD address or zero if none 

R3 = Default FM8 address or zero if none 

Output; C = 0/ operation successful 

= 1 , operation failed, F,SRR(R01 set 

Ail registers preserved 

Conditionals; None 

Directory processing in FCS appears someMhat coatplex the 
first tirae it Is examined- The following routines and entries 
are invoivad; 

DIDFND ..DIDF 
DIFMO ..DIDl ..DIO 

OIkFMD^ ,.oirf 
GSTDI ..GTDI 
CSTDID .GTDIO 
3STDIR .GTOIR 
PARDI ..PDI 
PiROID ..PDID 
PARSDI .PRSDI ..PSOr 

For the three user-level entries ( .GTDID, .GTDIR, and -PRSDI) the 
following flow occurs- iMote, for -PRSDI, there are three flows; 
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datas3t(i)j, defauit-?N8(2)^ aad naitherO): 



.GTDID 
..GTDI 
,.POTD 
..POI 
.. DIDF 



.GTDIR 
,.GTDI 
• « D £RF 
..DIO 



(1) (2) 
..'DIRF none 
..DIO 



(3) 

..?0I 

,.01RF 

..DID 



C.4.37 PliRSDV 



This module contains the code to parse the device name and 
assign the FDS's LON to the parsed device. 



Entry; .PRSDl, ..PSDV 

Input; RO = FOB address 

R1 = FNB address 

R2 = DSD address or zero if none 

R3 = Default FMB address or zero if none 

Output; C = 0/ operation successful 

= 1/ operation failed^ F.SRR(RO) set 

If .PRSDV/ all registers preserved 

If ..PSDVy- R0-R3 preserved, R4/R5 destroyed 

Conditionals; RS$ELP 



C.4.38 PARSE 



This module contains the routines to completely parse a 
file specification. The individual parsing modules fPARSDI 
PARSDV, and PARSFN) are called for each component of 
specification. 



The - routina- -» -STFrl is an 
fi lenama if no file-ID has b 
fails Into ..PiSS.- Qtiiaraise 



internal entry used to parse 
ean sat. If parsing, is needed# 
tile routine aiar9.iy exits-. 



th 

i 



Lntry; 



Input; RO = FD8 address 
Output: R1 = FN8 address 



rt <t> Cii S 
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RO prsservad/ R2-R5 dsstroyed 

The routines .PISSS and ..PARS parse a 
specif ication- 



^ntry. .PARSE/ ..PARS 

Input: RO = FOB address 

R1 = FM,a address 

R2 = DSD address or zero if none 

R3 = Default FNB address or zero if none 

Output: C = 0/ operation successful 

= 1/ operation failed/ F.ERR(RO) set 

If .PARSE/ all registers preserved 

If ..PARS/ R0-R3 preserved/ R4/R5 destroyed 

Conditionals: R$$ELP/R$$SPL 



C.4.39 PARSFN 



This fflodule contains the code to parse the filenaffle 



Entry: .PRSFM/ ..PSFH 

Input: RO = FOa address 

R1 = FSB address 

R2 = DSD address or zero if none 

R3 = Default FSB address or zero If none 

Output; C = 0/ operation successful 

= 1/ operation failed/ F.SRR(RO) set 

If .PRSFS/ all registers preserved 

If ,.PSFN/ R0-R3 preserved/ R4/R5 destroyed 

Conditionais:. Mone 



complat a 



This routine checks to see if the FDB is properly setup for 
record input and output. The file is checked to see if it has 
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baen opened and the proper I/O soda Is checlcad 
(saquantial/randos/block)- The aioaula is assaiabiad.- into tuo 
versions dapending on the dafinition of R.$5SSQ« 

The routine .-PGCR checks for proper randoa or sequential 
I/O. If randoffl 1/0/ it checks that the device is not sequential 
In nature. The routine ..PGCS checks for sequential I/O only. 
The calling argusients to both are the same. 



Entry: ..PGCay ..PGCS 

Input: RO = FOB address 

Output: C = 0/ operation OH: 

= 1/ operation illegal/ F.ERR(RO) set 



All registers preserved 



Conditionals: R$$SSQ 



C.4.41 PNTMRK 



This module contains the user routines for returning to a 
previously noted position in a file and for getting the current 
position in the file. A file's position is designated by a 
double-aord block number and a single vord byte aithin the 
block. 

The .POINT routine positions a file to a previous marked 
position. 



Entry: .FOIMT 

Input: RO = FOB address 

R1 = New ¥Bii number (high part) 

R2 = Mea ySH number (low part) 

H3 = Byte number within block 

Output:' C ~ 0/ o'peration successful 

= 1/ operation failed/ f.S RR(R-O) set 

Ail ca-gisters preserved 

The .MARK routine retrieves the current record position. 
The virtual block number is taken from the F.V3N doubleword. 
The byte number is calculated from the currant position in the 
block I/O buffer (F .NRSC+F.¥8S2-f .EOBB ). 
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Entry; .MARK 

Input; RO = FOB address 

Output; Rl = y 8 K. number (high part) 

R2 = ?3il number (losi part) 

R3 = Byte number aithin block 



R0,R4/R5 preserved 
Conditionals: Mona 



C.4.42 POIMT 



This module contains the internal code for repositioning a 
file. If the desired block is different from the current block 
the old block is written if dirty and the new block read. Th 
record pointers are then set up for the desired position. 



Entry: ..P!«l 

Input: RO = FD8 address 

Rl = New ¥BN number (high part) 

R2 = Mew VBM number (low part) 

R3 = Byte nuabar within block 

Output: C = 0/ operation successful 

= ly operation failed, F.ERR(RO) set 

RO preserved, Rl-RS destroyed 

Conditionals: R$$ANI,R$$88F 



C.4.43 POSIT 



This module contains the code for calculating the 
positioning information nacessary for use with .POUT for a file 
with fixed- length, records. 



Entry; .POSIT/ ..RSIT 
Input; RO = FOB address 



F.RCN#^ doubleword set to desired record number 
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Output: C = 0/ operation success 

■= 1/ operation failedy. F»SRil(.H0) sat 

I.£ succassfuiy following ragisters returned: 

R1 = ?BM nujabec (nigh part) 

R2 - number (low part) 

R3 = Byte number within block 

If .POSIT, R0,R4,H5 preserved 

If ..PS IT, SO preserved, R4, R5 destroyed 

Conditionals: R$$EIS 



C.4.44 POSSSC 



This module contains the routines used to position a 
fixed-length file to a specific record. Besides the entry 
documented below (.POSRC), the entries ..PSRl, -.PS8C, and 
..PSRG are also in this module, ioaever, they are merely call 
other routines are are therefore are not documented further. 



Entry: .POSRC 

Input: SO = FD8 address 

F.RCHM doubleword set to desired record 

Output: C = 0, operation successful 

= 1, operation failed, F.SRR(RO) set 

All registers preserved 

Conditionals; lone 



C.4,45 PPHA3C 



This routine translates a binary SIC into its ASCII, string 
r .epr esent-atioa. 



Entry: .PPASC 

Input: R2 = String address to store ASCII OIC 

R3 = Binary UIC {.BYTE owner, group) 
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R4 = Conversion Flags 

Bit 0=0, suppress leading zeros 
= 1, output laadiag zeros 
Bit 1 = 0, output saparators (1,3) 

= 1, suppress separator output 

Output: string output 

R2 = Last byte output+i 

R0,R1,I?3-R5 preserved 

Conditionals: R$$EI3 



C.4.46 PPMR50 



This routine translates a binary UIC Into two RAD50 words* 



Entry; •PPR50 

Input: R1 = Doubleword address to store RAD50 results 

R2 = Binary UIC (.BYTE owner, group) 

Output: Die converted to RAD50 

R0,H4, R5 preserved, R1-S3 destroyed 

Conditionals: None 



C.4.47 POT 



This aodule contains the code for outputting a logical 
record to the device/file. The module can be assembled for 
either sequential only support (R$$SEQ) or random/seguential 
support. See the RSX-ll/IAS I/O Operations Reference Manual, 
pages.' 3-23 to 3-28 for further details on calling sequence and 
r-eturn values. 



Entry: .PUT, .PDT3Q 

Input: RO = FD8 address 

Output: C = 0, record input 

= 1, operation failed, F-ERR(HO) set 
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Ail ragistars ?ras-3r¥€d 

Co nd i t io na i s : R $$ ASI / R $ $E IS , R $ $ RSL^ R $$ 3S Q, R $$ 1 1 M 



C.4.48 RDR»^ 

This routina inputs tha next virtual block/ writing the 
currant one if it is dirty {FD.MRT=1). 

Entry: ..RORS 

Input; RO = FOB address 

Output: C = 0/ operation successful 

= 1/ operation failed/ F,SRR<R0) set 

RO preserved/ R1-R5 destroyed 

Conditionals: None 



C.4.49 RDaAIT 



This ffloduls contains the routines for reading the next 
virtual block. ..RMAT increments the block number (F.VBN) and 
falls into ..R'nAC. It also checks for record-oriented transfers 
and handies them correctly. 



‘Entry; ..RWAT 

Input; RO = FOa address 

See ..RMAC for remaining description 

The routine ..RMAC reads the current virtual block. It 
only expects to be called for block i/G. 



Entry; ..RIAC 

Input; RO = FOB address 

F.¥8N(R0) = Slock number 

F.B08{RO) = Address of buffer header 

F.8BFS(RG) = Number of bytes to read 
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aiitputj. C. - 0/ operation succassful 

= 1/ operation failad^ F,£RR(R0) set 

F. MRSC(RO) = Address of start of block 
f.SOB8(RO) = Address of last oyte+l 

RO preserved^ R1-R5 destroyed 

Conditionals: R$$B8F/R$$MSF 



C.4.50 ROMRIT 



This aodule contains the coaaon routines for READ/MRITE 
I/O. The routine ..RMCK checks that block I/O is allowed. It 
checks that the fils is opened <F.D9D nonzero)^ REAO/MRITE mode 
is set (FD.RifM=l), and the device is block oriented (FD.REC=0). 



Entry: ..RiCK 

Input: RO = FD8 address 

Output: C = 0^ Block I/O alloHed 

= 1, Block I/O not ailoBad, F.ERR(RO) = IE-ILL 

All registers preserved 

The routine ..MTRO actually issues the block I/O requests. 
The block number is bumped after the I/O completes. 



Entry: ..MTRD 

Input: RO = FDB address 

R4 = I/O function code (IQ.MVB/IG.RVB) 

F.VBI(R0> = Block number to raad/Hclte 
F.8KD3(RQ) = Suffer descriptor 
F.BKST(RO) = I/O status block address 
F.SXDM(aO) = I/O done AST address 

Output: C = Of operation successful: 

- operation faiiad^ F.ERRCSO) sat 

RO preservea^ R1-R5 destroyed 



Conditionals: Mone 
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C.4,51 SEAO 



Tnl3 routine' is the US3C interface for reading a block via 
block I/O -aoda. Sea the R3 a- 11/IAS I/O Operations Reference 

Manual, pages 3-28 to 3-31 for furtliar details on calling 
sequence and return values. 



Entry: ..HEAD 

Input: SO = FD3 address 

Output: C = 0, operation successful 

= 1, operation failed, F.ERRfRO) set 

All registers preserved 

Conditionals; Hone 



C.4.52 REJiAME 



This routine is the user interface for renataing a file. 
Only the file's directory entry is manipulated, the filename 
internal to the file header is untouched. 



Entry: .RSNAM 

Input: RO = EDS address {old filename) 

R1 = FOB address (nea filename) 

Output; C = 0, operation successful 

= 1, operation failed, F.SRR(RO) set 

All registers preserved 

Conditionals: None 



Z' 4 ^ ^ HP 

This routine correctly sets up the FOB record pointers for 
locate mode I/O. If called for move mods, it is a no-op. 

Entry: ..RTAD 
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Input: RO = FOB adUrass 

Output; F.N38D<R0) = Set to record size, address 
R0rPl/J?3-S5 preserved/. S2 destroyed 
Conditionals; R$$AMI/R$$.88F 



C.4.54 RSTFD8 



This routine resets a FOB so it can be used for another 
open- If record I/O was used/ the block buffer is returned to 
the pool. Locations in the FOB that are assuaed to be zero if 
no file is opened are cleared. 



Entry: ..RFDB 

Input: RO = FOB address 

Output; FOB reset to non-opened state 
RO preserved/ R1-R5 destroyed 
Conditionals: R$$MBF 



C.4.S5 RMBLK 



This aodule contains the routines used to issue the 
read/ write requests for record I/O. The routines are used for 
both record and block oriented devices. The only difference 
between the entries is the I/O codes used. ..RBLK uses lO-RyB. 
..M8LK uses lO.MVB. 

The carriage control and ¥BM are always stored in the 
constructed QIO. Mhan issued to record devices/ QIO parameters 
4 and 5 are typically ignored- Siailariy/ block I/O devices 
ignora paraaetar 3» The .f/Q status block is assuaed to be at. 
the beginning, of the buff ar header/- which Is assuaed to be 
imsadiataly in front of the data buff ax- 

-lo implicit wait for I/O completion is made. The ■ carry- bit 

will be set only if the -QI.0 directive fails- 



Entry 



RBLK, ..MBLK 
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Input: RO ~ FD8 address 

SI = Adaress of data buffer 

R2 = Size of data buffer 

S3 = Carriage control character 

F.¥SH(R0 3 = 3 lock nufiJber ' 

Output: R1 = Address of I/O status block 

RO preserved/ S2-SS destroyed 

Conditionals: R$$M8F 



C.4.56 RMFSR2 



This module contains a collection of routines to allou the 
user to read and arite fields in $SFSR2- The routines (•RDFDR/ 
.MDFDR/ .RDFFP, .MOFFP, .RFOiM/ .WOiSM/ . RDFUI, and -liDFOI) ar e 
described in the R3X-11/IAS I/O Operations Reference Manual/ 
pages 4-2 to 4-6. 

( 

C-4.57 RMLOMG 



This routine is used to perform block I/O transfers yhen 
tae byte count is greater than one block (512 bytes). This 
routine is selected by the .READ/.MRITE routines uhen 
appropriate. Otherwise/ ..MTRO is used. 



Entry; ..RMLG 

Input; RO = FD8 address 

R4 = I/a function code (lO.RyB/rO.MVa ) 

FOB setup for block I/O request 

Output: C = 0/ operation successful 

= 1/ sparation failed/ F.SRIKHO) -set 

ill registers prasarved 
Conditionals: Mona 
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€*4.53 TRMCL3 

This routina truncatas a- fiia to ■ its EOF position and 
closes the file. 

Entry: .TPMCL 

Input: RO — FDB address 

F.EfBK, F.FF8Y set to EOF position 

Output: C = 0/ operation successful 

= 1 , operation failed^ F.SRR(RO) set 

All registers preserved 

Conditionals: Mone 



C.4,59 UDIRSC 



This module contains the user interface routines for 
issueing the directory primitive functions: find filename 
(.FliD), enter filename (.EMTER), and remove filename {.REMOV). 
The calling sequences and return values are documented fully in 
the RSX-ll/IAS I/O Operations Reference Manual/ pages 4-12 to 
4-14. 



Entry; .FIMD/ .ENTER/ .REMO? 

Input: RO = FDB address 

R1 = FNS address 

Output: C = 0/ operation successful 

= 1/ operation failed/ F.SRR(RO) set 

Ail registers preserved 

Conditionals: R.$$Nia 



C.4.50 upniao 



This routine provides extended file lookup abilities for 
SCS-11 systems. It is not compiled for RSX-llM systems 
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C.4.61 »A1TI 



This module contains routines used to issue QIO's for ?CS 
and yait for their coaplation. The first routine/ 
issues a QIO and falls Into ..MAIT* It watches for errors due 
to insufficient pool and will loop/ waiting for a significant 
event if this happens. 



Entry: ..QIOM 

Input: RO = FDB address 

R4 =1/0 function code 

Scratch DPB setup in $$fSR2 

Output; C = 0/ operation successful 

= 1/ operation failed/ F.SRR(RO) set 

R1 = I/O status block address 

RO preserved/ H2-R5 destroyed 

The routine ..WAIT stores the I/O status into F.ERRCRO). 
It waits for I/O completion by waiting for a non-2ero I/O status 
value. If the I/O status is zero/ it falls into ..MASF and then 
repeats. 



Entry: ..MAIT 

Input: RO = FDB address 

R1 = I/O status block address 

Output: C = 0/ I/O completed successfully 

= 1/ I/O failed/ F.ERR(RO) set from status block 

All registers preserved 

The routine ..MAEF waits for the FDB's event flag/ 
F.EFM(RO). If no event flags was specified/ event flag 32(10) 
is used. The flag is cleared after the wait completes. 



Entry: ,,MAEF 

Input: RO = FOB address 

Output: Event flag cleared 

Ail registers preserved 




FCS-11 M00ULS3 



PAGE C-41 



Conditionals; flona 



C.4.62 a'AITG 

This routine is the user interface for laaiting for I/O 
completion ahen perforaing block I/O* If an I/O status block 
has been specified (F.BKST nonzero)^ the routine .-.MAIT is used- 
Otherwise, the routine .-MASF is called. 

Entry; .MAIT 

Input; RO = FD8 address 

Output; I/O Halt coaipleted 

All registers preserved 
Conditionals; Hone 



C.4.63 »AINOD 



This routine checks the I/O status for errors due to 
insufficient pool CIS.yPM) and doers a Hait-for-signif leant 
event if true. Otheraise it merely returns. 



Entry; ..WAMD 

Input; RO = FOB address 

R1 = I/O status block address 

Output; C = 0, IS.OFM occured, uait completed 
= 1, Error uas not IE- 0PM 

All registers preserved 

Conditionals; Sone 



C.4.64 aAISST 



This routine waits for I/O completion and sets up the 
record pointers based on the contents the the second I/O status 
word. 
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Entry t ,.MAST 

Inputs RO - FOB address 

R1 = i/Q status block address 

I/O status is assusad to be at start of buffer 
descriptor* 

Output: C = Oy I/O coaipiated successfully 
= 1, I/O failedy F.ER8{R0) set 

F.SREC(RO) set to begiiming of data 
F.EQ88(R0) set to end of data 

R0yRlyS3-R5 preservedy R2 destroyed 

Conditionals; R$$S8F 



C.4*65 MRITE 



This routine is the user interface for writing a block via 
f' block I/O mode. See the RSX-ll/IAS I/O Operations Reference 

Manualy pages 3-31/ 3-32 for further details on calling sequence 
and return values. 



Entry: .3RITS 

Input: RO = FOB address 

Output: C = 0/ operation successful 

= ly operation failed/ F«S8R(R0) set 

All registers preserved 

Conditionals: ilone 



C.4.66 MTSAIT 



This aodule contains 
virtual block. ..WIMA 
record buffers set up for 



the routines 
outputs the 
the next PUT. 



for writing the next 
IBU and returns with the 



Entry: ..iXSA 

Input: RO = FD8 address 
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F. ¥8H(R0) = Block mifflber 

F.BDB(RO) = Address o:£ buffer haadar 

F«8aFS(R0) ■= liuHiber of bytes to read 



Output: C = 0/: operation successful 

= 1/ operation failady F«SRR(R0) set 

F.HREC(RO) = Address of start of block 
F.E0B8(R0) = Address of last byte+1 

RO preserved, R1-R5 destroyed 

Conditionals; R$$88F,R$$M8F 



C.4.67 XQIQI 



This module contains the routines used to build and issue 
internal FCS QIQ's. They use the QIO DPB in $$FSR2. The 
routine .«XQI0 sets up the standard paraaeters and issues the 
QIO directive* It assuaes the I/O paraaeters have already been 
set- This routine gets the I/O status block address and AST 
address from the FOB- 



Entry; --XQIQ 

Input: RO = FOB address 

R3 = Directive code, size 
R4 = I/O function code 
R5 = DPB address 

Output: See --XOIl below 

An alternate entry is --XGI1- This routine is passed the 
I/O status block address and AST address- It gets the lun and 
event flag from the FD8, sets up the DPB, and issues the I/O 
r 8 quest - 



Entry: --XQI1 

Input: RO = FD8 addrass 

RI = I/O status- block addrass or zero 
R2 = I/O Dona AST address or zero 
R3 = Directive code, size 
R4 = I/O function code 
R5 = OPB address 

Output: C = 0, operation successful 

= 1, QIO directive failed, F-ERR(RO) set from 
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$.0EH 

R1 =1/0 status biock aadress 

SO/ 84 preserved/ R2 / S3 /R5 destroyed 

The routine ••IDP9 initializes the DPB in $$FSR2 
returns the address of the paraffleter araa- 

Entry: ..IDPB 

Input: Mone 

Output: R5 = Address of parameter area 
R0-R4 preserved 
Conditionals: Mone 



C.4.68 XQIOU 



This routine is the user interface for issuing a 
request using the lun and event flag from the FOB. 



Entry; .XQIO 

Input: RO = FOB address 

R1 = I/O function code 

R2 = Size of parameter list or zero if none 
R3 = Address of parameter list 

Output: C = 0/ operation successful 

= 1/ operation failed, F.SRR(RO) set 

All registers preserved 



and 



QIQ 



Conditionals: Hone 




4PPEMDIX D 



FILE3-11 QIO'S 



This section documents the various QIO's used by Files-11 
(FllACP and MTAACP)). The material is taken from an article 
arltten by Andrau Goldstein of Digital in Hovembery 1976 and 
from examination of various source modules. 



D.l FILS 3-11 a IQ DP8 



All FllACP QIO directive parameter blocks have the same 
format. The folloHlng diagram illustrates this format (note 
only the parameter fields are different from all other QIO's); 



j j 

I Size i Die I 

j 1 J 

1 Function Code | Modifier i 

I 1 , 

1 Reserved I LON I 

I , 

I Priority I EFM I 

— — 1 

I I/O Status Block I 

I J 

I AST Address I 

I J 

j FID Pointer I 



I Attribute List Pointer I 

1-^ 1 

I Extend Control I Oaita Size (gigh)' I 



1 Delta Size (low 16 bits) f 

I 1 

i Access Control I Mindou Size 1 



I J 

I FM3 Pointer I 

J J 



Q.IOFN Q.IOFH 
Q.IOLO 
Q-IOPH Q.IOSF 
Q.IOSB 
Q. lOAE 
Q.IOPL 
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Sach parasetar flalci is used for a specific ourposa. If 
the partictiiar. 310 does, not raqulca- the fi-eidjr it .must, not be 
specified (set to zero). FlllCP range checics all parameter 
fields. 



0.2 FILS 3-11 QIO P.ARAMETSRS 



This section will discuss the six parameter aords in a 
Flles-11 QIO. While none of the paraiaeters require the FCS data 
structures, it is obvious tne fields are set up for use in the 
FCS environment. 



0.2.1 Parameter Word #1 - FIO Pointer 



This aord contains the address of a three aord block in the 
issuing task's space. This block is or a ill become the file ID. 
If the word is zero, no file ID is speclfied- 

In the FCS environment, this aord alll typically contain 
the address of the filename block. The file ID block has the 
folloaing format: 



1 File Mumber 1 

I j 

J File Sequence Mumber I 

i Reserved j 

I 1 



The file number is used by FllACP as an index to the file 
header block in the index file- The file sequence number Is 
used to maintain header integrity- Each time a header block is 
used for a nea file, the file sequence number Is incremented. 
The final aord has no current meaning. 



D. .2..2 Parametar. liora #2 - Attribute List- Pointer 



This word contains the address of an attribute list in the 
issuing task's space. This list controls ahich file attributes 
are to be read or written by FllACP. If no attribute list is 
specified, the aord is zeco- 

File attributes are various fields in the file header- 
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These fields are docuaentad in Appendix F of the ■ IA3/RSX-11 I/O 
Operations Rafarenca Manual ( AA-2515C-TC) » 

An attribute list consists of zero to six attribute 

entries;^ followed by a byte of zero. Each attribute entry has 

the following format: 

•BYTE <At tribute type>y<H> 

.aORD <Pointer to '?J' byte buffer> 

The sign of the attribute type deter mines the direction of 
the operation. If the attribute type is negative^ the attribute 
is read from the file header to the buffer. If the attribute 

type is positive, the buffer is written to the file header as 

the new attribute. The laagnitude of the attribute type and size 
of the buffer deterialne which fields in the file header will be 
accessed. The following table lists all valid read attribute 
types, valid buffer sizes, and the starting offset in the file 
header. To write the attribute, make the sign of the attribute 
type positive. 

-01,02 Read file owner UIC (H.FOM8). The OIC is a binary 
word. The low byte (fl.PROG) is the owner number. 
The high byte (H.PROJ) is the group number. Note 
that the file owner UlC is independent of the 
directory OIC. 

-01,04 Read file owner OIC, protection (a.FOMM). The UIC 
is returned as described above. The second word is 
set to the file protection code (see attribute 
- 02 , 02 ). 

-01,05 Read file owner OIC, protection, characteristics 
(H.FOWN). The OIC and protection are returned as 
described above. The fifth byte is set to the 
user-controlled character ics (see attribute 
-03,01). 

-02,02 Read protection (H.FPRQ). The file protection word 
is a bit mask with the following format; 

Bit 15 12 11 87 43 0 

I 1 — j I 

I' Borid I Group 1 Owner i System i 

I- 1 1 I 

Each of the four categories above has four bits. 
Each bit has the following meaning with respect to 
file access: 
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Bit 32 10 

j 1 I j j 

1 Oaiete I S-Xtana ( arita } Read I 

I —I 1 j 

A bit value of zero (0) indicates the respective 
type of access is allowed to the file. A bit value 
of one (1) indicates access is denied. 

-02/03 Read protection/ characteristics (H.FPRO). The 
protection is raturned as described above. The 
third byte is set to the user-controlled 

characteristics (see attribute -03/01). 

-03/01 Read characteristics (H.UCHA). The user 

characteristics is a one byte field containing 
various bit definitions. The current bits defined 
are listed below: 

OC.COM = 200 Logically continuous file, lihen the 
file is extended/ this bit is 
clear ed- 

UC-OLK = 100 File irap roper ly closed- Mhen ever 
the file is opened for write/ this 

bit is set. It is not cleared until 
the file is closed (deaccessed) « 

This is the famous lock bit. 

In addition to the user-controlled characteristics/ 
the next byte in the header is the 
system-controlled characteristics. This byte 
cannot be accessed by an attribute field. The 

current bits defined in this byte are listed below: 

SC.MDL = 200 File marked for delete. 

SC- BAD = 100 Bad data block in file- 

-04/40 Read record I/O area (U.OFAT). The first 7 words 
of this area are a direct copy of the first 7 words 
of the FD8 when the file is opened {see Table A-1/ 
I/G Qperations Refarenca Manual/ offsets F.RTYP to 
F,-FFB¥). The raaaining'9 yocds of this area are 
not used. I io- aot know how.^ this area' is defined 
in the case of RMS-H. 

-05/06 Read filanajae (I.FMAM). The filename is stored as 
nine (9) RAD50 charactars- 

-05/10 Read filename/ type (I.FSAM). The filename is 
returned as described above- The type is returned 
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to the' fourth aord (see attribute -06^02)« 

-05^12 Read filenaae, type, version (I.FHAM). The 
filename and type are ceturnad as described above - 
The version is returned to the fifth aord (see 
attribute -07,02)« 

-06,02 Read type (I-FTYP). The type Is stored as three 
(3) RiOSO characters. 

-06,04 Read type, version (I.FTYP). The type is returned 
as decsrlbed above. The version is returned to the 
second aord (see attribute -07,02). 

-07,02 Read version (I.FVER). The version is stored as a 
binary nuaber. 



MOTE 

The filename, type, and version are set 
ahen the file is created. If the file is 
renamed by PIP, these fields are not 
changed. 



-10,07 Read expiration date (I.EXDT). The expiration date 
is intended to be the time the file becomes 
eligible for deletion. This feature is not 
iaplefflented. The date is kept in ASCII fora in the 
format day, month> and year (2 bytes, 3 bytes, and 
2 bytes). 

-11,12 Read statistics block. The statistics block is 
defined in Appendix H of the I/O reference manual. 
So specific fields exist in the file header for 
this attribute. Therefore, it cannot be written. 

—12,00 Read entire file header. The buffer size is 
assmaed to be 1000(8) bytes. This attribute has no 
corresponding writa function- 

-13,02 Read block size (ANSI labeilad. tape only). The 
block size is returned as a positive 16-bit number 

-14, XX Read_ussr label (ASSr labelled tape only). This 
attribute allows access to the user label on an 
AMSI standard tape. *’xx" is the length of the 
label (maximum 80), If the function is a read, 
user header labels are read if a file is accessed. 
If no file is accessed, user trailer labels are 
read. If the function is a write, user header 
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laiseis are writ tan during a create- Osar trailer 
labels are i^citten - during a ■ daaccass. 

-15^ XX Read complete date information (disk files only) 
This attribute allots the ravlson, creation#- and 
expiration dates to be read. Oates are stored and 
returned in the format day (2 bytes)^ month (3 
bytes)y and year since 1900 (2 bytes). Times are 

stored and returned in the format hours (2 bytes), 
ninutss (2 bytes), and seconds (2 bytes). '*xx*' 
bytes of time/day information are returned in the 
folloaing format: 

00-01 Revision number. This number is 

incremented each time the file is 
closed after being opened for output. 

02-10 Revision date. 

11-16 Revlson time. 

17-25 Creation date. 

26-33 Creation time. 

f' 

V 33-42 Expiration data. 

+16,16 Allocation control (disk files only). Used for 
file placement control, currently by RMS only. 
Processed only by create or write (i.e., write 
attribute only). 

The magitude of the attribute type determines the maximun 
valid buffer size. Any smaller size is legal. The sizes listed 
above are sufficient to handle the named attributes. The 
largest size for each attribute is also the largest buffer 
allowed. 



D.2.3 Parameter Words #3 and #4 - Size/Extend Control 



These two paraiaeters are- used to specify how many blocks 
are to be allocatad to new file or added to an existing- fils. 
The words are also usaa to control the type of block ailocation. 
The format of the two parametars is as fallows: 

«8fTS <Delta size (high 8 bits) >/ <£x tend control> 

.WORD <Delta size (low 16 bits)> 

The high bit of parameter word #3 (bit 15) controls whether 
the remaining fields are used by FllACP. If the bit is zero 
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(0)^ no siza change is desired. If the bit is one (1)^ the 
r affiaining,- fields.- are- processed. 



The high byte of pa.raaet3r aord #3 (extend control) 
detarisines the type of allocation desired. The iou byte of this 
word and paraffletar word #4 fora a 24-bit nuaber of blocks to 
allocate (delta size). This nuaber is the Initial file size in 
the case of a create and the change in size in the case of an 
extend. 



The extend control byte consists of a bit aask. The bits 
have the following meanings; 

Sit 0 All blocks must be allocated contigously (EX.ACl). 

Sit 1 Allocate largest contigious chunk up to delta size 
(EX.AC2). This bit is not examined unless bit 0 is 
on (1). 

Bit 2 File must end up contigious at operations end 
(EX.FCO). 

Bit 3 Use volume default as delta size (EX.AOF). 

Bit 4 Placement control is desired (SX.ALL). 

Bit 5 Unused. 

Bit 6 Unused. 

Bit? Enable extend (EX.EMA) (see above). 



D.2.4 Parameter Word #5 - Mindow Size/Access Control 



This word is used to specify the window size (low byte) and 
the access control (high byte). The word is processed if the 
high bit (bit 15) is one (1). If this bit is zero (0)r the word 
is disabled. The format of the word is shown below: 

•BYTE <Mindow 3ize>,<Access control> 

The window size is the number of mapping entries the sindow 
is. to hold at once. This is- not t. he. window 3.1z3 in bytes. If. 
t,he byte is zero^ the volume daf.ault is used. 

The access control byte consists of a bit mask. The bits 
have the following meanings; 

Bit 0 Lock file from further accesses for write and/or 
extend (AC.LCK). 
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Bit 




Snaole^ 


deaccasS' lock (AC.DLX). 


BIT 


2 


Enable 


block locking (AC. LXL). 


Bit 


3 


Enable 


explicit block unlocking (AC, 


Bit 


4 


Unused 




Sit 


5 


Unused. 




Sit 


6 


Unused. 




ait 


7 


Enable 


access (1C. SMB) (see above). 



D.2. 5 Parameter Word #6 - Filename Block Pointer 



This aord contains the address of a 13(10) word block in 
the issuing task's space. This block is the filename block. 
See Appendix 3 in the I/Q Reference Manual for a description of 
a filename block. If the aord is zero, no filename block is 
specified. 

If the QIQ function is a directory operation (lO.FMA^ 
IQ.RNA/ lO.SNA}^ the directory ID field (S.DIfl) of the filename 
block is used. Files-11 directories are merely files with names 
of the form C0/01gggooo.0IR;i ahera CO/03 refers to master file 
directory and '*ggg** is the group number and ”ooo** is the ouner 
number. The master file directory is the file aith ID 4^A,0 and 
is also entered in the master file directory- The directory for 
OFD C123,4563 is the file £0,03123456.018)1 



D.3 FILES-11 QIO FUMCTIQNS 



This section Hill discuss the various functions processed 
by FllACP- This functions are normally issued by FCS or RMS, 
hoMever, the clever user can use them directly and save the 
overhead of the run-time systems. 

The folioaing. are the. functions ispiamentad by FllAC?. 
5.ach function is foiloaed by a list o.£ required and optional 
parameters. If a parameter is not listed, it must be set to 
zero. Also, paraaetar 4 is not shown as it is a part of 
pa raffle tar 3. 

10. CPE Create File 



#1 - FID block pointer, FID value returned with ID 
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of file created. 

^2 - arlta attribute' control list- (optional). 

#3 - Slza/extand control (optional). 

#5 - Access control (aaF be non-zero but aust be 
aisabled). 

10 -DSL Delate or Truncate File 

#1 - FIO block pointer (optional if file is 
accessed) - 

f3 - Size/extend control- If not present or 
enabled/ file is deleted- Otheryise/ the 
reaaining 31 bits specify the size the file is 
to be after truncation- 

IQ-ACR Access File for Read Only 
lO-ACW Access File for Read/lni rite 
IQ-ACE Access File for Read/Mr ite/Sxtend 

#1 - File ID pointer- 

#2 - Read attributes control list { optional) - 

#5 - Access control. 

IQ-DAC Deaccess File 

#1 - file ID pointer (optional). 

#2 - Write attribute control list (optional). 

#5 - Access control (may be non-zero but must be 
disabled) » 

IQ-SXT Extend File 

#1 - File ID pointer (optional if file aready 

accessed) - 

#3 - Size/extend control- 
10. RAT Read Attributes 

#1 - File ID pointer (optional if file aready 

accessed) - 

#2 - Read attribute control list- 
ID-WAT Write Attributes 

#1 - File ID pointer (optional if file aready 

accessed) « 

#2 - Write- attribute control list. 

I0-?yA Find Filanaiae in Directory 
lO.RMA Remove Marne from Directory 
lO-EMA Enter Mame into Directory 

#5 - Access control (may be non— zero/ but must be 
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disabied). 

#6 - Filename block pointer.. 

Tha follOMlng table suffliaarizes the optional and required 
parameters for aacii I/O request. The key to tbe table is as 
f oil OHS : 




* = Required parameter. 

0 = Optional parameter. 

A = Optional if file already accessed. 

D = May be non-zero, but must be disabled (bit 15 = 

0 ). 

If the entry is blank, the parameter must be zero or the I/O 
Hill be in error. Par meter 4 is a part of parameter 3 and is 
not listed in the table. 



I 1 1 1__^ } 

! Function I P 1 1 P 2 I P 3 | P 5 i P 6 i 

1^ 1 1— j — j 1 

! 10. ACE 1*10 1 1*1 ! 

! IQ.ACR I * I 0 i 1*1 I 

I 1 j 1 j— } 

I 10. ACM 1*101 1*1 I 

I 1 1— 1 1 } 1 

1 lO.CRE 1 * I 0 I 0 I D 1 I 

1 IQ.OAC 10101 101 1 

j I 1 1 j 1 i 

! 10. DEL i A i 101 1 I 

j j 1 1 i 1 

1 10. EM I I 1 I D I * I 

I 1- j- j— ..j J— 

I IQ. EXT I A I 1*1 i I 

j ^-1 J 1 1 ^-1 

I lO.FMA 1 i 1 1 D I * I 

I 10. RAT I A 1 * I I I 1 

I j j } j j 

I lO.RMA 1 I 1 101*1 

I 1 j -I J } 

I IQ. MAT i A I * I i ! 1 



D.4 PLACSMEMT CONTROL 



One undocumented feature of Flles-11 is placement controi- 
This feature ailoas the create or extend functions to specify an 
exact or approxomate position to allocate the desired blocks. 
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Placsaent control is iaplaiaent'ed by an attributa list entry. 
The p iacament. attribute is. J/alld for either the 10- CHS or 10. SIT 
functions and if used^ must be the first attribute in the 
attribute list. The format of the placement control attribute 
block is as follows: 

.BYTE <Placeaent control>^0 

•MQRD <High order bits of ¥8M or LBS> 

•MORD <Loa order bits of ¥8i or L¥8> 

.SLXs^ 4 COptionalj/ see below) 

The placement control byte consists of a bit mask. The 
bits have the following meanings 5 

Bit 0 Set if block specified is ¥BM^ otheralsa LBM is 
assumed (liL.VBM)- 

Bit 1 Set If approximate placement is desired^ otherwise^ 
* exact placement is assume (IL.AFX). 

SIT 2 Set if starting and ending LBN information is 

desired (AL.LBN). 

Bit 3 Unused. 

Bit 4 Unused 

8it 5 Unused. 

Bit 6 Onused- 

81 t 7 Unused- 

If AL.LBN is set, the control block must be 16(8) bytes 
long. FllACP will retiirn the starting LBM in the first two 
optional words and the last LBM in the last two optional words. 
Otherwise, the attribute size must be 6 bytes- If AL.¥BN is 
specified, AL.APX must also be set and the attribute will 
allocate the new blocks as close to the specified block as 
possible. This is useful if file extensions are desired to be 
as close to the previous as possible- 



0.5 3LGCX LOCKING 



Another undocumented feature of Files- 11 is block- locking 
support. This feature was iiapleraented to support RMS, however, 
it can be used for FC3. Locking only occurs for access to 
shared files and AC.LKL sat in the access control byte. For FCS 
users, this can be done by setting the FA-LXL bit in the F.ACTL 
field of the FDB before opening a file shared- From then on. 
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whenever a user reads or writes a block/ the systea will insure 
no otner user can have accesses to it. If the block is locked/ 
the second access will have a lock error (lE.LCK) returned to 
it- This feature/ when properiy used/ ailoas smitipia readers 
and writers to the sasne file. 

There are two options for unlocking blocks. The simplest 
method is to unlock the block whenever a new block is read or 
written. This will occur when the AC.SXL bit is set in the 
access control byte. FCS users can enabled this feature by 
setting the bit in the F-ACTL byte of the FOB. 

If the application requires multiple block locks# an unlock 
QIO is used to unlock blocks. To unlock a block# the lO.ULK 
function is issued with the folloaing parameters. 

Parameter #1 - Always zero. 

Parameter #2 - Zero or number of blocks to unlock. 

Parameter #3 - Always zero. 

Parameter #4 - High part of VBfi number or zero. 

Parameter #5 - Low part of VBM number or zero. 

Parameter #6 - Always zero. 

If all the specified blocks are currently unlocked# an 
error will be returned (IS.OLK). If no V8N and count is 
specified# ail currently locked blocks are unlocked If all I/O 
is completed. If a user is waiting for I/O# this could leave 
some blocks locked because the I/O was not finished. If a 
and not count is specified# the first lock-list entry with the 
specified V8H is unlocked. Therefore# If the user issued two 
requests for the same ¥8M with different sizes# the first one 
encountered will be unlocked. The order of locked blocks bears 
no relationship to the order the orignal reads/writes were 
issued- finally# if a VBM and count are specified# an exact 
match is located. 




APPEMDIX E 



SAMPLE ACP 



Included with the manual distribution is a saopla AC? and 
its associated device driver. The kit also includes sources for 
sample ACP enabling and disabling tasks. 



£.1 saaRCES 



The software Implements a OCP— stype ACP. No system 
modifications are< required to run the sample ACP. The file 
ACPSEM.CMD is an indirect command file that will assemble and 
taskbuild all sample software. The other files in the kit are 
as follows: 



COMACP.MAC - Prefix file used to define special symbols 
used by the ACP and its device driver. 

NOLACP.MAC - Source for sample ACP. The ACP performs no 
useful operations. However^ it does demonstrate 
packet dequeuing, device mounts and dismounts, I/Q 
process creation and teriaination, and data transfers 
from an ACP to a user task. 

MOLD RV. MAC - Source for sample driver. The driver contains 
a loadable database supports two devices (ACO:, ACl:). 
The driver demonstrates how ACP packets are processed 
and queued to an ACP. 



SilASLS.MAC - Source for basic MOLIC? mount tasx- This task 
performs the basic, steps rsquir -ad for enabling an. ACP. 
It supports- switches - to- specify- the AC? task name 
(/AC?=name) and volume control block size (/¥Ca=size}. 
The /PRM=’*stcing" switch can be used to pass an ASCII 
string to the ACP. 

0ISA8L.MAC - Source for basic SOLACP dismount task. This 
task performs the basic steps required for disabling 
an ACP- It supports the /PRM="string** switch. 
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tilGLTST.FQR - Sourca for test package for saraple softs«iare:. 
This- is- a fortran program that queries- the- user for- 
the I/G function to issue and can be used to test the 
other software- 

The kit also includes coataand files to link all tasks. The 
ENA8LD.CMD file alloMs the default ACP task name and volume 
control block size to be set. The current defaults are ”SULACP" 
and 2 bytes respectively. 



S.2 PRQCSDURS 



The procedure for using the sample code is to execute the 
ACPGES command file and generate the tasks. The listings should 
then be printed and read. The ACDRV should be loaded using the 
MCR LOA command and MULACP mounted using the ...ENA task. The 
SOLTST task can then be used to issue I/O requests to the ACP 
and report success/failure. Mhen finished^ the mounted devices 
can be dismounted with the ...DIS task and the driver unloaded. 

The sample ACP processes I/O packets by outputting an 
appropriate message to the console terminal and returning 
success to the user task. The softsare is intended to be used 
in conguction uith the manual^ particular ly^ Chapter 3 uhich 
outlines the designed processed used in the development of the 
sample AGP. The sources can also be used as a starting point 
for a user-aritten ACP. 
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OSSR-yfRlTTSM ACP'S 



This appendix describes various uaer-Hrltten ACP's that 
have bean reported to the author- The author uelcomes new 

additions- Please send a description of your ACP to the 
following address; 



Ralph li|- Staaerjohn 
Monsanto/ Zone TIA 
800 M. Lindbergh 
St. Louis, MO, 63166 



The submission should be typed and follow the format used for 
the currant submissions- Please limit the description to one 
page if possible- 
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DAPACP 

AiithorJ Ralph Stajaerjohn Oatei 17-APR-80 

Addrass: Hoasanto/ Zone Tli Phone; (314) 694-4252 

800 M. Lindbergh 
St. Louis, MO, 63166 



DAPAC? iiapleaents Olgitai's Data Access Protocol (DA?). The ACP 
is interfaced to FCS and allows RSX-llM utilities and languages 
to transparently access reaote flies on other RSX-llM and 
OSCsysteia-lO systeas- For example, normal Fortran I¥ Plus I/O 
statements can be used to read and write remote files. 




ACP-Style : 

I/O Functions Codes; 
Serial/Paraliel; 

T r aas po rt ab 11 i ty : 
Pool Otllizatlon; 

Mounting; 

Oisaountlng; 

FCS Support; 

RMS Support; 

Contact Author; 
Avaiiabiity; 

References; 



UCP, using pseudo driver as gateway 

Uses 31(10), subfunctions 
Parallel 

Requires meiaory aanageoent, SIS 
Minimumal, uses internal ACP pool 

Uses alternate task 
Uses altercate task 

Yes 

No 

Yes 

Mor proprietary Monsanto software 

Reports of the OSCsysteia-10/20 Fall ' 
U.S. DECUS Meeting, pages 57-65. 
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